Slashdot Mirror
Debian Release Mgr. Proposes Dropping Some Archs
smerdyakov writes "In this story posted by Andrew Orlowski of the Register Debian Release manager Steve Langasek has announced that support will be dropped for all but four computer architectures. Among the reasons cited for doing this are improving testing coordination, 'a more limber release process' and ultimately a ('hopefully') shorter release cyle. The main architectures to survive will be Intel x86, AMD64, PowerPC and IA-64." Actually, the story says clearly that this is only a proposal at this point, but it's definitely something to watch.
Original email
.. They will still have support for the other architectures, but seem to imply it must meet certain criteria to be considered for release.
They seem to imply it is a proposal to drop the actual releasing after sarge
IMHO: requiring a level of 98% is too high and only releasing if you can still buy is rediculous. Debian still mostly compiles for 386(on x86) and it's hard to buy a 386 these days.
As an active Debian developer, I simply want to state: this is anything but final and not at all decided. I am only one of many developers against the proposed scheme, and especially against the way in which the scheme was devised -- in a closed meeting with only a few select members, and completely without soliciting any input from the community.
In the long run, Debian may well have to concentrate more on some architectures than others, but a radical step such as the one proposed will probably not fly well with the community. Since our users are our top priority, you can expect many more emails on the topic before anything will happen.
echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
is that only those 4 archs will be actively supported in Debian _releases_. Other architectures will still exist and maintained but not be included in the shifts from unstable->testing->stable.
If it's that it might be a good things, granting the more popular(?) architectures a smaller turnaround time for stable releases.
Or maybe hell freezes over.
Not at all. The IA-64 is Intel's Itanium architecture which was massively redesigned. It is not compatable at all with x86 or AMD64 and is actually closer to the PowerPC, as both are RISC chips. The Itanium hasn't done very well (IBM just stopped selling it for their own POWER arch) but it it still used, and probably is at least #4 on servers.
This post written under Gentoo-linux with an SCO IP license.
gentoo runs quite a few mips architectures.. check out their support here:l
http://www.gentoo.org/doc/en/mips-requirements.xm
Gentoo supports at least as many architectures as Debian. A cursory glance at packages.gentoo.org will tell you that.
LOAD "SIG",8,1
Why bother keeping IA-64? Debian has more alpha users than ia64. There are more SPARC users. Heck, there are even more HPPA users than ia64 users. All the details are available at the Debian Popularity Contest.
The phrase "dropping support" is misleading. They're dropping the "stable" release for these archs. They are moved into a category called "second class citizen" architectures.
"unstable" -- which is what hacker-type individuals tend to run anyway (and is both much more up-to-date and not particularly unstable) -- will continue for all. As most of the affected archs fall into the "mostly for hackers" category, this change should have little real impact. I suppose the exception might be the sparc.
The benefit of all this is (besides, maybe, faster releases) that they have a plan for adding new scc archs easily.
[I think the "scc" archs will also not use the Debian mirror network, but probably don't have enough users to receive any real benefit from it either.]
We live, as we dream -- alone....
If everything was well-written and accounted for differing word lengths, byte orders, etc. then we wouldn't be having this conversation. Unfortunately, that's not the case. On the plus side, Debian's dedication to platform equality means that a lot of bugs get exposed (and fixed) that no one would ever know about if the world only ran x86. This is a good thing for everyone, even those where that software already worked as expected.
Dewey, what part of this looks like authorities should be involved?
Even the trolls can't be bothered to read the damned thing. Debian will still be available on all those plaforms, but Debian Stable won't be after Sarge releases.
If this proposal passes.
If I have been able to see further than others, it is because I bought a pair of binoculars.
The way I understood it was that each architecture would continue to be included in unstable, but when time came to release stable, the architectures that were not up to snuff would not be included in stable. In other words, they are not going to hold off on releasing stable for the architectures that are ready just because some other, less actively devloped ones are not. This seems fair. If someone wants their favorite architecture to be included in the next stable release then they can volenteer to get it up to stable quality, or commit themselves to maintaining it (security patches) after it is released. Otherwise they can just keep using the unstable. This is better than forcing everyone to use unstable, by holding debian back from releasing stable on a timely basis.
The second set of requirements (for SCC) also make sense. If you have less than 50 users, or cannot support the infrastructure needed make mirrors, there is no reason that all the ftpmasters should have to mirror a full branch of code for you - it is overkill. Those 50 people can get together set up their own apt-get repository for their binary packages.
There are several things that I did not like about this plan however, like the non-merit-based requirement, of requiring a machine to be purchasable new. If there are people that are willing to do the work, who cares if the machine is in production or not.
I also don't like the fact that there is no official option for the less active arch's to make stable releases uncoupled from the main stable timescale. Suppose that a minor arch, has enough support to do a stable release every 3 years compared to the x86's 18 month cycle. Choosing to target every other stable release won't work because while there is twice as much time between releases the bottleneck is the time between feature freeze and release, and that will still be determined by the x86 team's (faster) schedule. Furthermore, all the stable releases for all the architectures really should have the same package versions. This will save effort supporting the releases in the future (security patches etc), and keep user confusion down to a minimum. One possible solution would be if they kept the requirements listed, but did not require them to be met at the same time as the x86 branch - let the architectures enter stable when they are ready, with a time limit of say 2 or 3 release cycles of the x86 branch.
In general, requiring all the architectures to walk in lockstep is a real problem that debian needs to fix, but they should do so in a manner that allows the less active architectures to continue to have stable releases at their own pace, while not holding back the x86 line.
A machine installed today may look nothing like a machine installed tomorrow.
You may want to take a look at FAI (Fully Automatic Installation - google will find it). We've been using it quite successfully for that kind of maintenance.
You basically set up a local debian mirror (snapshot of the real tree) and use it to deploy your machines (FAI does it great) and as only apt-source for them. Whenever it's time to update a pkg you test it, then just drop it to your mirror where the clients can pick it up via apt-get upgrade.