Debian changing release policy
The much larger consequence of this meeting, however, has been the
crafting of a prospective release plan for etch. 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 reality is that keeping eleven
architectures in a releasable state has been a major source of work for
the release team, the d-i team, and the kernel team over the past year;
not to mention the time spent by the DSA/buildd admins and the security
team. It's also not clear how much benefit there is from doing stable
releases for all of these architectures, because they aren't necessarily
useful to the communities surrounding those ports.
Therefore, we're planning on not releasing most of the minor architectures
starting with etch. They will be released with sarge, with all that
implies (including security support until sarge is archived), but they
would no longer be included in testing.
This is a very large step, and while we've discussed it fairly thoroughly
and think we've got most of the bugs worked out, we'd appreciate hearing
any comments you might have.
It looks like the Debian core developers have realized that trying to keep the little used platforms in synch is holding up releases too much. This change in plans is still a proposal and will not effect the Sarge release. But there are enough core people backing this that it's just arguing over the details now.
We project that applying these rules for etch will reduce the set of
candidate architectures from 11 to approximately 4 (i386, powerpc, ia64
and amd64 -- which will be added after sarge's release when mirror space
is freed up by moving the other architectures to scc.debian.org).
This will drastically reduce the architecture coordination required in
testing, giving us a more limber release process and (it is hoped) a
much shorter release cycle on the order of 12-18 months.
Architectures that are no longer being considered for stable releases
are not going to be left out in the cold. The SCC infrastructure is
intended as a long-term option for these other architectures, and the
ftpmasters also intend to provide porter teams with the option of
releasing periodic (or not-so-periodic) per-architecture snapshots of
unstable.
I think it is rather odd that IA64 makes the cut as a full release, but neither SPARC nor alpha did. Looking closer, it doesn't appear that the list of included platforms is final yet though. Other platforms that can show they have enough backing can get upgraded. If they stick by the rule that you have to be able to buy new machines for that platform though, I don't think much will get upgraded and IA64 won't be on the list for more then a release or two.
I'm not sure if this is the best way of going about it, but Debian really did have to do something to speed up the release cycle. The offical Debian stable is several years old and based on a 2.2 kernel.
Jay
