5 Currently snapshot.debian.net is operated by a single individual on their
6 hardware at home. It is a service archiving old binary and source packages.
7 Access to old packages, which have in the meantime been deleted from the
8 regular debian archive, allows Developers and Users to debug upgrade problems,
9 to check when regressions were introduced, to check if old packages had been
10 miscompiled, to downgrade to older versions while bugs are being fixed etc.
14 * Two systems with sufficient storage, hosted somewhere not in the US (so we
15 can import old non-US into it).
16 * Storage should be at least on the order of 8T (currently snapshot.d.n is
17 using about 4T), and easily expandable
18 * remote management stuff
22 * Joerg Jaspert/ftpteam
28 A service by ftpmaster to host larger arch-all packages for datasets like
29 scientific databases (e.g. RCSB PDB, a database of protein structures) or
32 This service could (and probably should) share hardware with snapshot.
36 * ftpteam/Joerg Jaspert
39 ## new debian mail setup
41 A set of systems that will handle all incoming mail for all debian systems.
42 Currently our incoming mail handling is on the individual host hosting a
43 service, i.e. on master.debian.org for @debian.org, on bugs.debian.org for the
44 bug tracking system, on lists.debian.org for our mailinglists and on several
45 other systems for their individual, smaller email traffic.
47 Centralizing email handling will allow us to maintain our anti-spam measures in
48 a single point, avoiding duplicate work and hopefully improving our success.
52 * Four or so systems, in at least two different locations, capable of handling
53 modern anti-spam software. This probably needs a bit of CPU.
54 * remote management stuff
61 We probably have sufficient hardware for this. Current plan involves using one
62 new box from HP, murphy, a new old sparc that zobel gets from some place, and
63 puccini that will soon no longer have packages on it.
67 Currently bugs runs on a single DL385g1 system which cannot keep up with the
68 load that the BTS causes.
70 Owner@bugs would like to split the BTS accross multiple hosts: two for incoming
71 email and spam filtering (would not be required if we had the setup mentioned
72 above), one master, and at least two user-facing web servers.
74 Requirements (assuming the above mentioned mail system is in place, else add
77 * two systems with fast disks (we don't need that much storage, some 200 gigs
78 should suffice easily for a while - say 4x140 gig raid10), some ram for
79 caching (say 16g?), and the CPU to handle the scripts (if we can get two quad
80 cores per box that would be great)
81 * one master that processes incoming email, changing bugs as required, and
82 pushes the changes to the web facing servers
88 If the snapshot hosts go through we might be able to put the bugs front end
89 webservers on them too. Probably a question of load but it can't hardly be
90 worse than rietz at the moment.
95 I'd like to use Ubuntu's merge-o-matic to generate diffs between Debian's
96 source archive and the source archives of various other Debian-based distros
97 (Knoppix, Freespire, Mepis, Sidux, gNewSense and so on). The result will be
98 much like patches.ubuntu.com. merge-o-matic downloads source packages, unpacks
99 them and generates diffs against unpacked pure debian source packages. As a
100 result lots of disk space would be required since the whole Debian archive plus
101 an unpacked version of it and the same for each derivative distribution is
106 * a system with sufficient disk space (how much is that?)
115 Idea: A machine which has all sources extracted from orig.tar.gz + diff applied for all dists.
119 * a system with sufficient disk space (how much is that?)