Drop the merge.d.o proposal because it is running on snapshot.d.o already
[mirror/dsa-wiki.git] / input / hardware-wishlist.creole
index 562f2f2..1737372 100644 (file)
@@ -36,6 +36,23 @@ Proposers:
 * ftpteam/Joerg Jaspert
 
 
+
+== source.debian.org ==
+
+Idea: A machine which has all sources extracted from orig.tar.gz + diff applied for all dists.
+
+Requirements:
+
+* a system with sufficient disk space (how much is that?)
+
+Proposers:
+
+* Noel Koethe
+
+= Historical =
+
+These proposals probably are no longer relevant:
+
 == new debian mail setup ==
 
 A set of systems that will handle all incoming mail for all debian systems.
@@ -62,6 +79,16 @@ We probably have sufficient hardware for this. Current plan involves using one
 new box from HP, murphy, a new old sparc that zobel gets from some place, and
 puccini that will soon no longer have packages on it.
 
+Status (2009-05-02):
+
+We probably still eventually want to move to a more cenralized setup for all
+the low-traffic leaf-sites, but momentum on the Big Mail Setup Change seems
+to have pretty much died.  Since Stephen put quite a lot of work into making
+our exim setup more readable, maintainable and we are using the same config now
+everywhere, at least some of the reasons for this proposal are no longer valid.
+It still might make sense to eventually move @debian.org mail from master to a new
+system but we don't need 4 dedicated hosts for that, probably.  (weasel)
+
 == new bugs.d.o ==
 
 Currently bugs runs on a single DL385g1 system which cannot keep up with the
@@ -77,9 +104,9 @@ two mail servers):
 * two systems with fast disks (we don't need that much storage, some 200 gigs
   should suffice easily for a while - say 4x140 gig raid10), some ram for
   caching (say 16g?), and the CPU to handle the scripts (if we can get two quad
-  cores per box that would be great)
+  cores per box that would be great).
 * one master that processes incoming email, changing bugs as required, and
-  pushes the changes to the web facing servers
+  pushes the changes to the web facing servers.
 
 Proposers:
 
@@ -89,38 +116,14 @@ If the snapshot hosts go through we might be able to put the bugs front end
 webservers on them too. Probably a question of load but it can't hardly be
 worse than rietz at the moment.
 
+Status (2009-05-04):
 
-== merge.d.o ==
-
-I'd like to use Ubuntu's merge-o-matic to generate diffs between Debian's
-source archive and the source archives of various other Debian-based distros
-(Knoppix, Freespire, Mepis, Sidux, gNewSense and so on). The result will be
-much like patches.ubuntu.com. merge-o-matic downloads source packages, unpacks
-them and generates diffs against unpacked pure debian source packages. As a
-result lots of disk space would be required since the whole Debian archive plus
-an unpacked version of it and the same for each derivative distribution is
-needed.
-
-Requirements:
-
-* a system with sufficient disk space (how much is that?)
-
-Proposers:
-
-* Paul Wise
-
-
-== source.debian.org ==
-
-Idea: A machine which has all sources extracted from orig.tar.gz + diff applied for all dists.
-
-Requirements:
-
-* a system with sufficient disk space (how much is that?)
-
-Proposers:
-
-* Noel Koethe
+We were quite successful in using other hosts as bugs web mirrors (even if
+right now we aren't running any due to other hardware failing), so that is
+a more or less solved problem.  We also intent to move bugs-master to a kvm
+domain at ubc/ece once the blade there is fixed.  And we can probably move
+incoming MX to a blade instance in darmstadt and another one at the same
+place as new bugs-master will be if the bugs folks still want that.
 
 == new ftp-master ==
 
@@ -133,11 +136,6 @@ raid6, either internal or external for the master copy of the archive in the ran
 of 2-4T (is that right, ftp folks?).  Additionally some faster internal storage
 could be useful for the database part of the ftp archive (4 disks raid10?).
 
-== new backup.d.o ==
-
-bartok, the current backup.d.o, is getting old too, and there is not all that
-much spare space.
-
-We should be looking at replacing that eventually.  A raid6 of big SATA disks
-would probably provide the required robustness and be cost-effective.
+Status (2010-05-20):
 
+HP DL380 G6 machine in place at CS Dept. Brown University. In setup