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

March 16, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

The big news from the Debian Project this week is a proposal from the Release Team and FTP masters that may result in several architectures being "dropped." The Debian release team and FTP masters are proposing some criteria to determine which architectures will receive stable releases after sarge:

The release team and the ftpmasters are mutually agreed that it is not sustainable to continue making coordinated releases for as many architectures as sarge currently contains, let alone for as many new proposed architectures as are waiting in the wings.

The proposal would not affect the Sarge release, but would take effect for the next stable Debian release, dubbed "Etch." The architectures that are slated for release with Sarge will still go out the door, and will have security support throughout Sarge's release cycle, but would not be included in testing for the Etch release.

The proposal would relegate a number of architectures to "second class citizen" (SCC) status, though even that does not come for free. At a minimum, the architecture must have a functioning Debian build system ("buildd") which can run 24 hours per day without crashing. It would also require five Debian developers that use or work on the port to send a signed request for its addition, binaries for the port would need to be built and signed by Debian developers, include "basic Unix functionality", and binaries would need to be built from unmodified Debian source. Finally, the architecture must be freely usable, and the port would require a sufficient user base, or 10% of downloads "over a sampled set of mirrors."

To be part of the Etch release, an architecture would have to meet yet another set of criteria. The target systems must be available for purchase, they must be able to compile at least 98% of the distribution's packages, there must be a working installer, and there must be a machine under debian.org, available to developers, for testing. It would also be necessary for the security team, the system administration team, and the release team to sign off on accepting the architecture.

We followed up on the proposal with Steve Langasek, one of the Debian Release Team members. Using this set of criteria, Langasek predicts that this would reduce the candidate architectures from 11 (for Sarge) to 4 for Etch -- x86, PowerPC, IA-64 and AMD64. The list of ports is not set in stone. Langasek told LWN that he hopes other ports will "strive for inclusion in the Etch release, and that their efforts will contribute to maintaining the high quality we have today even if they don't end up being released."

We also asked Langasek how the Release Team had picked the criteria to be used for future releases.

One of the items in the agenda I had set for this meeting in Vancouver (with input from the rest of the team) was to talk about setting per-architecture criteria for etch to address some of the problems we've seen during the sarge cycle, where we've been fighting fires involving one architecture or another not being able to keep up -- and what we've noticed is that it's not consistently any particular architecture, it's been spread out across the board, so we really needed to tell people up front what we needed from ports in order to get etch out on-schedule.

As it turns out, the ftpmasters ran with this idea in a late-night brainstorm session even before the meeting officially began, and had some preliminary criteria put together by Saturday morning. By Saturday evening, we'd hammered this into something we all agreed was a good idea, and spent the next couple of days tweaking, refining it as one thought or another popped into someone's head.

The release team has invited comments on the plan, and it is undergoing quite a bit of discussion over on debian-devel. We asked Langasek if the proposal would be dropped if there was a strong reaction against it. Langasek said that the Release Team was open to ideas, and was "happy to tweak the specific criteria in use if there are reasons to do so." However, Langasek said that setting basic requirements "shouldn't be all that controversial, because the only alternative to holding our ports to a standard that reflects the demands of the release process really is a slow, unpredictable release." He also said there might be tweaks for ports not deemed release candidates.

It is pretty clear based on feedback that something more than the proposed unstable snapshot mechanism is desired for those ports that aren't going to be "release candidates". We don't know yet what form that will take, but there's been a lot of good discussion about what the needs are that should be met.

One criteria for release candidates that caught our eye was the requirement that the architecture must be "publicly available to buy new". We wondered if that would mean dropping support for 386 and 486 chips, something that other distributions have done for some time. According to Langasek, processors with the 486 instruction set are still in use.

The truth is that it's still possible to buy chips implementing a 486 instruction set, and a lot of people are still doing interesting things with them in the embedded sphere -- and it doesn't really cost us anything, release-wise, to maintain backwards-compatibility with those chips.

There have been a few ABI changes recently that have made current software dependent on an instruction set that's only available in 486 chips and higher; it's possible to emulate around this, but the only implementation currently available has security problems, so it may yet turn out that sarge is the first release of Debian's "i386" port that doesn't actually support true 80386 processors. We've also dropped support in sarge for the oldest of the 32-bit Sparc processors, for similar reasons.

From where we're sitting, this looks like a reasonable proposal. It doesn't arbitrarily drop specific architectures, but allows for ports to be dropped from Etch's release candidates if they fail to keep up. This may not be the "magic bullet" needed to ensure more timely releases from the Debian Project, but it should contribute to faster releases overall.

Index entries for this article
GuestArticles	Brockmeier, Joe

to post comments

A modest proposal from Debian's Release Team

Posted Mar 17, 2005 3:21 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

the biggest problem with this (as I pointed out in the earlier story) is the requirement that a port must be 10% of download from the mirrors

as someone else pointed out this would eliminate all ports except i386 according to the current measurements, I think they said the PPC was the next highest at 3%

allowing some ports to release later is not a bad idea, but saying that the secondary ports won't ever 'release', but instead just provide 'snapshots' (which won't have security team support) invalidates one of the big reasons to have a release (anyone can setup their own mirror and snapshot that to use themselves, simply providing a snapshot doesn't help anyone much)

A modest proposal from Debian's Release Team

Posted Mar 17, 2005 10:12 UTC (Thu) by grouch (guest, #27289) [Link]

> the biggest problem with this (as I pointed out in the earlier story) is the requirement that a port must be 10% of download from the mirrors

Agreed. If such a requirement applied to operating systems in general, GNU/Linux itself would never have been downloadable. Something just doesn't feel right about an arbitrary 10% cut-off, but I'm not a Debian developer so I can't really squawk too much.

A modest proposal from Debian's Release Team

Posted Mar 17, 2005 10:18 UTC (Thu) by nijhof (subscriber, #4034) [Link] (1 responses)

the biggest problem with this (as I pointed out in the earlier story) is the requirement that a port must be 10% of download from the mirrors

There was a bit of confusion for that, but that is not a requirement for the architecture to be released -- only for the architecture to be carried by ftp.debian.org. Architectures that have fewer downloads, would be carried by ssc.debian.org, or ports.debian.org or whatever -- and would be released from there, if they meet the release criteria.

So this 10% requirement is decoupled from the release criteria.

A modest proposal from Debian's Release Team

Posted Mar 18, 2005 7:31 UTC (Fri) by dlang (guest, #313) [Link]

so this means that the debian mirror system with be i386 only as nothing else qualifies?

the mirror system is more then just a way to save bandwidth on the master server, it also lets people avoid congested international lines and survive server outages

why should those advantages be thrown away?

I'll bet that there are packages in the i386 port that are used significantly less frequently then some packages in the 'minor' ports, if you're going to save space on the mirror servers look on a per-package basis instead of per port (yes it will mean some work to figure out the refrences for those people who do actually want those packages, but it's not _that_ hard)

A modest proposal from Debian's Release Team

Posted Mar 17, 2005 17:51 UTC (Thu) by ballombe (subscriber, #9523) [Link] (3 responses)

> 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.

A modest proposal from Debian's Release Team

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

> 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] (1 responses)

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.

80386 vs i486

Posted Mar 17, 2005 23:03 UTC (Thu) by pm101 (guest, #3011) [Link] (1 responses)

Just out of curiousity, anyone know what changed from 386->486 that makes Debian stop supporting 386? I recalled the two being fairly close cousins at the time (at least compared to the previous 8086->[->186]->286->386 transitions). I'm wondering what the relevant thing that the 486 added was.

80386 vs i486

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

1) The change is in current stdlibc++: it uses xchg for atomic operations which >=80486 only.

In fact it is possible to build current stdlibc++ for 80386, but it will have an ABI incompatible with all others GNU/Linux distributions, so Debian did not consider it acceptable.

2) Debian still support 386 through kernel emulation, you need to install the kernel in the upgrade-i386 prior to upgrade to sarge.
See http://higgs.djpig.de/upgrade/upgrade-80386/

A modest proposal from Debian's Release Team

Posted Mar 25, 2005 16:30 UTC (Fri) by Darkstar (guest, #28767) [Link]

Anyone know how this would affect Debian/MIPS? It's one of the only available Linux distros that install without any trouble (i.e. without netbooting ;-) on my SGI Indy. I guess since Indy's aren't manufactured anymore, this arch would also be dropped, right?