A modest proposal from Debian's Release Team [LWN.net]

A modest proposal from Debian's Release Team

Posted Mar 17, 2005 17:51 UTC (Thu) by ballombe (subscriber, #9523)
Parent article: A modest proposal from Debian's Release Team

> From where we're sitting, this looks like a reasonable proposal.

It is not. Debian history was written by porters. Debian infrastructure was made by porters for enabling ports. That won't change on a whim. Removing architectures with a very active porters team won't happen.

A lot of Debian developer have expressed their disconfort with that proposal, notably the Stable Release Manager and main Security Officer.

Debian is a volunteer effort: if there are enough people willing to work on a port, Debian will release the port. The Release team cannot change that.

(Log in to post comments)

A modest proposal from Debian's Release Team

Posted Mar 17, 2005 20:29 UTC (Thu) by madscientist (subscriber, #16861) [Link]

> Removing architectures with a very active porters team won't happen.

Right, it won't. But that doesn't mean the proposal is not reasonable.

The proposal doesn't limit the number of architectures in a release to any specific number, or list any specific set. If an architecture has enough of an active developer base to meet the criteria, it will be released. I don't think publishing a fair and equitable set of requirements that needs to be met before an architecture becomes "tier 1" is a bad thing: it's a GOOD thing.

Obviously some work needs to be done on the exact criteria to make sure they are fair and equitable (I agree with LWN that the "available for purchase new" one is a bit off; if there are buildd servers that work properly 24/7, as described in other requirements, then who cares if you have to go to Ebay to buy the parts? When you can't get parts anymore, the architecture will definitely start failing to meet one or more of the other criteria anyway.)

A modest proposal from Debian's Release Team

Posted Mar 18, 2005 1:30 UTC (Fri) by ballombe (subscriber, #9523) [Link]

The proposal only make sense if the number of released arch drop down significantly (say to 4 archs).

There are 12 architectures currently that could easily meet all the criterions that are fair. The 2 "unfair" requirement being "available for purchase new" and "at most 3 buildd" (i.e. must be very fast).

If you remove these two "unfair" requirements, you have 12 architectures to release and the proposal is a no-op.

Even with the two "unfair" requirements, it is not clear that you will go below 8 archs.

A lot of powerful hardware has been given to the project but is not used as buildd because the ftp-master don't feel the need and so don't take the trouble to set it up.

For example arm is certainly 'available for purchase new' and Debian could use arm box much faster than netwinder as buildd.

A modest proposal from Debian's Release Team

Posted Mar 18, 2005 17:40 UTC (Fri) by madscientist (subscriber, #16861) [Link]

> The proposal only make sense if the number of released arch drop down significantly (say to 4 archs).

Not so: the proposal only makes sense if the to-be-released architectures are all able to maintain good quality, security infrastructure, etc. to ensure that Debian releases are made at reasonable intervals. I think we can all agree that both woody and sarge have unacceptably long release cycles. The goal of the proposal is to make sure that etch doesn't have that problem. There is no other reason to drop architectures!

Now, there is obviously debate about whether this is really the problem that causes long release cycles, and more debate about how exactly to cull out releases if necessary, and even more debate about how to handle those releases which are demoted to tier 2.

But the goal of timely, regular releases is something Debian HAS to come to grips with in the etch timeframe, or they might as well decide to not bother releasing at all and leave that to their partners like Ubuntu. I personally really liked the "channels" proposal where the release would be broken out into a small number of "channels" that would be released on their own schedule: something like "base OS", "X", "KDE", "Gnome", then a bunch of others. Obviously there is a lot of thinking about how this would work, but if it worked it would go a long way towards satisfying the different needs of server/desktop/etc. folks.

BTW, I don't necessarily agree with your placing of the buildd restriction into the "unfair" category. The amount of time it takes to rebuild packages has a direct impact on the ability to release and to make security updates, and lots of low-powered buildd systems has its own issues.