I wrote: > Don't try for such a perfect and well-tested release. > Require successful installs on all arches and major platforms before > freezing. The two options above are unappealing, and hard, so I'm leaning toward this one: > Swtich to testing-style udeb propigation. > > It would really be better if instead of copying a release to > testing in one lump, we copied individual udebs to testing when > they're ready. I have outlined some of the technical problems > with using purely automated system as used for deb testing > propigation in an earlier mail, but maybe we could do a manual > propigation. It would probably involve a lot of work, and would > probably slow down what did get in, but that may not be > inappropriate at this point. udebs would be manually propigated to testing individually or in small groups on the basis of installation reports and testing. This would have the disadvantage of making it very hard to do things that touch most of the installer, such as adding a new language. The same problems that arise when getting translations into Debian proper would apply. It would also mean that the beta4 netboot and floppy installs could be broken as udebs in testing were updated. We would need to redirect some users to the sarge_d-i images, so that the stuff in testing got tested as a whole, while still referring some users to sid_d-i, so new bits could get tested before reaching sarge. Maybe by directing users who file installation reports with a problem in sarge_d-i to try again when it's fixed in sid_d-i. -- see shy jo
Attachment:
signature.asc
Description: Digital signature