Andrew Suffield dijo [Mon, Oct 20, 2003 at 07:57:20AM +0100]: > So, we have two scenarios. Let the package be broken in such a way > that it builds differently on different platforms. > > a) All packages uploaded to the archive are built in an artifical > environment. All packages in the archive function as expected. > > b) The package is uploaded from real-world environments. Sometimes it > breaks; when this happens the bug is noticed and corrected, so that > the package always builds the same way. > > I say that (b) is vastly superior to (a). The tradeoff is temporary > bugs in sid versus unnoticed bugs in a release. We'll never trap all > the bugs, but going out of your way to _not look_ cannot be a good > idea.
I would prefer (a) over (b) - Yes, it breaks more, but that is exactly what we want: We want broken packages to appear as seldom as possible in the archive. I think a third (or, after reading some replies to this same mail, fourth, fifth or nth) way could be used: Binary packages enter Sid as usual. Now, after the 10-day period, when they are ready to enter Testing, they are autobuilt. Only the autobuilt version hits Testing. This will help us reduce the load on autobuilders, as not every probably-buggy version will be autobuilt. It will also help maintain Testing's quality/stability, as all packages entering it will have proof of at least being buildable. Of course, for human developers, this might mean a bit of extra work, finding out why the heck did it not compile as planned when entering Testing, as we will have to check for specific versions and probably work in chroots or similar environments (which we already sometimes need)... But testing will be cleaner, which is a Good Thing. This will also solve one additional thing: many packages have not hit Testing (or have been held for too long) because one of their dependencies is stuck in Unstable. If packages that prove that _by themselves_ introduce no new bugs are allowed into testing, this will be less of an issue. (Now that... Well, yes, some important libraries such as glibc will have to trigger myriads of autobuilds when they finally enter Testing, in order to ensure that things are still OK - This seems a bit scary, but at least interesting ;-) ) This last consideration might kill the first advantage I talked about (reducing buildd workload), but I think it can help us have a stabler Testing distribution. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
signature.asc
Description: Digital signature
