I see several problems with freezing potato in one week: . Our Incoming directory still contains 350MB of unprocessed (NEW or changed) packages. They ought to go into potato.
Adding them just a few days before potato is frozen would be stupid since they can't be tested well. Not adding them is also stupid since they were ment for potato and some of them probably contain useful additions for potato (like OpenSSH or the new GPL'ed CAD program), or splitted packages. . Our boot-floppies are not ready yet. Freezing the distribution without working boot-floppies will extend the freeze time which would be a very bad idea. Adam di Carlo today told me that he doesn't believe that our boot-floppies will be read before January. (Since I haven't been able to work on them I can't say anything about that.) . When we freeze now, we will probably have to extend the freeze time for several weeks or months. This will make potato quite out-dated at the time we may release it, just like it has happend with the slink freeze. We should not make that same mistake again. . Freezing now and extending the freeze time may affect Debian being frozen during xmas where only few people can work on it. . I still haven't seen an announcement what to do with the FHS transition and which policy versions should be used for potato packages. Additionaly when I have asked other developers they could only shrug their head. There *is* confusion wether to use /usr/share/man or /usr/man, /usr/share/info or /usr/info and /usr/share/doc or /usr/doc, also where, if and when to add softlinks somewhere. Therefore I propose to postpone the freeze (and the release) for at least two months, hoping to get the FHS issue, Incoming and boot-floppies resolved. Thanks for your attention, Joey -- Linux - the choice of a GNU generation.
pgp9uCJqZbhGj.pgp
Description: PGP signature