Adrian Bunk wrote: > Not after October 1st 2003 it sould have been clear that the progress > of the installer wasn't as good as expected. This was 2 months before > the announced release date. > > What would have been a second plan? > Nobody likes boot-floppies. > But considering the choice between releaseing Debian 3.1 with the new > installer in 2005 or releasing Debian 3.1 with boot-floppies in 2003, it > might have been possible finding some Debian developers hacking > boot-floppies to use them for Debian 3.1 . > > The new installer would have been ready in time for Debian 3.2 . IIRC when we did this for potato, getting the woody boot-floppies updated to work with the new kernel and potato took something on the order of 6 months. Do not make the mistake of thinking the boot-floppies were maintainable. Expecting them to be ready in two months would be impractical. Also, bear in mind that if we'd have done that, then we would still be where we are right now, but would not have the debian installer ready to release with sarge. > What would have been a second plan? > Use testing-proposed-updates. testing-proposed-updates is _still_ missing autobuilders. > Consider a MUA maintained by a MIA developer with the following bugs: > - #1 missing build dependency (RC) > - #2 MUA segfaults twice a day (not RC) > > Consider the two possible solutions: > 1. a NMU fixing #1 > 2. - ensure that the maintainer is MIA > - orphan all packages of the MIA maintainer > - new maintainer adopts MUA > - new maintainer fixes both bugs > > The first solution has a quick positive effect on the "RC bug count" > metric. > The second solution looks worse in this metric, but it's actually better > for the users of Debian. I doubt that many people NMU for RC bugs without also looking at the recent release history of the package and checking to see what other bad bugs the package may have. -- see shy jo
Attachment:
signature.asc
Description: Digital signature