[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Source only uploads?

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.


Gunnar Wolf - gwolf@gwolf.cx - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Attachment: signature.asc
Description: Digital signature

Reply to: