I believe that the Red Hat process which has Fedora for home users (with a rapid release cycle and new versions of software but support for only about one year) and Enterprise Linux (with a ~18 month release cycle, seven years of support, and not always having the latest versions) gives significant benefits for the users.
The longer freeze times of Enterprise Linux (AKA RHEL) mean that it often has older versions of software than a Fedora release occurring at about the same time. In practice the only time I ever notice users complaining about this is in terms of OpenOffice (which is always being updated for compatability with the latest MS changes). As an aside, a version of RHEL or CentOS with a back-port of the latest OpenOffice would probably get a lot of interest.
RHEL also has a significantly smaller package set than Fedora, there is a lot of software out there that you wouldn’t want to support for seven years, a lot of software that you might want to support if you had more resources, and plenty of software that is not really of interest to enterprise customers (EG games).
Now there are some down-sides to the Red Hat plan. The way that they run Fedora is to have new releases of software instead of back-porting fixes. This means that bugs can be fixed with less effort (simply compiling a new version is a lot less effort than back-porting a fix), and that newer versions of the upstream code get tested. With some things this isn’t a problem, but in the past I have had problems with the Fedora kernel. One example was when I upgraded the kernel on a bunch of remote Fedora machines only to find that the new kernel didn’t support the network card, so I had to talk the users through selecting the older kernel at the GRUB menu (this caused pain and down-time). A problem with RHEL (which I see regularly on the CentOS machines I run) is that it doesn’t have the community support that Fedora does, and therefore finding binary packages for RHEL can be difficult – and often the packages are outdated.
I believe that in Debian we could provide benefits for some of our users by copying some ideas from Red Hat. There is currently some work in progress on releasing packages that are half-way between Etch and Lenny (Etch is the current release, Lenny will be the next one). The term Etch and a half refers to the work to make Etch run on newer hardware [1]. It’s a good project, but I don’t think that it goes far enough. It certainly won’t fulfill the requirements of people who want something like Fedora.
I think that if we had half-way releases of Debian (essentially taking a snap-shot of Testing and then fixing the worst of the bugs) then we could accommodate user demand for newer versions (making available a release which is on average half as old). Users who want really solid systems would run the full releases (which have more testing pre-release and more attention paid to bug fixes), but users who need the new features could run a half-way release. Currently there are people working on providing security support for Testing so that people who need the more recent versions of software can use Testing, I believe that making a half-way release would provide better benefits to most users while also possibly taking less resources from the developers. This would not preclude the current “Etch and a half” work of back-porting drivers, in the Red Hat model such driver back-ports are done in the first few years of RHEL support. If we were to really follow Red Hat in this regard the “Etch and a half” work would operate in tandem with similar work for Sarge (version 3.1 of Debian which was released in 2005)!
In summary, the Red Hat approach is to have Fedora releases aimed at every 6 months, but in practice coming out every 9 months or so and to have Enterprise Linux releases aimed at every year, but in practice coming out every 18 months. This means among other things that there can be some uncertainty as to the release order of future Fedora and RHEL releases.
I believe that a good option for Debian would be to have alternate “Enterprise” (for want of a better word) and half-way releases (comparable to RHEL and Fedora). The Enterprise releases could be frozen in coordination with Red Hat, Ubuntu, and other distributions (Mark Shuttleworth now refers to this as being a “pulse” in the free software community [], while the half-way releases would come out either when it’s about half-way between releases, or when there is a significant set of updates that would encourage users to switch.
One of the many benefits to having synchronised releases is that if the work in back-porting support for new hardware lagged in Debian then users would have a reasonable chance of taking the code from CentOS. If nothing else I think that making kernels from other distributions available for easy install is a good thing. There is a wide combination of kernel patches that may be selected by distribution maintainers, and sometimes choices have to be made between mutually exclusive options. If the Debian kernel doesn’t work best for a user then it would be good to provide them with a kernel compiled from the RHEL kernel source package and possibly other kernels.
Mark also makes the interesting suggestion of having different waves of code freeze, the first for the kernel, GCC, and glibc, and possibly server programs such as Apache. The second for major applications and desktop environments. The third for distributions. One implication of this is that not all distributions will follow the second wave. If a distribution follows the kernel, GCC, and glibc wave but not the applications wave it will still save some significant amounts of effort for the users. It will mean that the distributions in question will all have the same hardware support and kernel features, and that they will be able to run each others’ applications (except when the applications in question use system libraries from later waves). Also let’s not forget the possibility of running a kernel from distribution A on distribution B, it’s something I’ve done on many occasions, but it does rely on the kernels in question being reasonably similar in terms of features.
Isn’t this exactly what Ubuntu’s 6-monthly releases are? Take unstable, fix the worst bugs (but by no means all, hence my comment on your previous post) and ship it on a regular schedule. There’s certainly a market for it, and plenty of community support.
“””
I think that if we had half-way releases of Debian (essentially taking a snap-shot of Testing and then fixing the worst of the bugs) then we could accommodate user demand for newer versions (making available a release which is on average half as old).
“””
As a longtime reader and someone who deeply respects your opinion, you are describing Ubuntu pretty much to a tee. If Debian had been able to solve their social problems and do this a few years ago, Ubuntu would cease to exist.
if you look at http://fedoraproject.org/wiki/Releases/HistoricalSchedules you will see that Fedora sticks to 6 month schedule pretty well and it is not “9 months in practice”. Fedora is not Debian.
On community support for RHEL/CentOS/Scientific Linux — there are actually a few third-party repositories with a great deal of additional software compiled for these systems. RPMForge seems to be the largest, but there’s also ATrpms, and the Fedora folk put together EPEL (which is a bit more conservative both about what packages it makes and how they’re updated). Some of these folks are working on a consolidated repository called rpmrepo; although it seems to be taking a long time for the infrastructure to come together, I’m expecting that it will take away a lot of my packaging work for $WORK.
Red Hat has no concept of a “stable” release – they do long term support in version 4.x – but in fact 4.0 is significantly different from 4 update 4, 4.5 and 4.6 with changes throughout. So much so, that they’ve gone to 4.5 and 4.6 not as updates but as full point releases. 5.0 is now different from 5.1.
Debian is, actually, the only distro that does long term support and _doesn’t_ change e.g. versions of GCC in the middle “Etch and a half” with kernel updates to accommodate newer hardware is a good compromise. If you assume that you get a new Debian once every two years, with oldstable supported for about a year, a release of ” and a half” every 18 months is about right. ISTR Joey Hess doing “Potato and a half” or similar for a book. Ubuntu releasing every six months doesn’t actually help sustained development: snapshot Sid, add some “Testing” and do the user tweaks then it’s time to roll out with no sustained testing. This all IMHO
Ani: You are correct, I was mostly thinking about the period around FC3 to FC5 (when I was last at Red Hat).
James and Jeff: It’s interesting to know that Ubuntu is doing what I advocate. I have never really looked into what Ubuntu are doing. I’ve got some clients who want me to do Ubuntu stuff so that will change in the near future.
Ubuntu would not cease to exist unless Mark wanted it to. I get the impression that Mark’s plans are much grander than merely running a distribution, so he would continue on his current course regardless. Maybe if Debian had done things differently before Mark decided to found Ubuntu then he would have done something different with his time and money, but only he could comment on that possibility.
This is a difference between Ubuntu and other distributions. Some distributions disappear due to lack of interest. But as long as Mark is interested he can make it happen.
Claire: Yes, I use RPMForge and have used ATrpms in the past. The current practice of having a single RPM for a repository that updates the list of YUM sources as well as providing the GPG key is really neat. But my experience is that they haven’t provided timely updates of programs such as Amavis/Clamav and that such programs are packaged in a way that makes them a little more difficult to use than the equivalent Debian packages, and generally more difficult to manage than the native Fedora/RHEL packages.
Andrew: There is a lot of debate about what changes should go into an update of a stable release. For my use the RHEL model is a better fit than the Debian model. There is of course nothing preventing the creation of a model which would have 4.0.1 and 4.1.0 being released at the same time where 4.0.1 has the most important bug fixes and support for new hardware and 4.1.0 has some new features.
What is the real difference between an Ubuntu 6 monthly release and a Sid snapshot with some testing and tweaks?
Synchronizing stable Debian releases with Red Hat sounds like a good idea.
Also, please see Joey Hess’s idea about “Constantly Usable Testing”. Almost all the goals he sets have already been achieved. You just need to decide that Debian wants to release snapshots of Testing and then, well, just do it. :)
http://kitenet.net/~joey/code/debian/cut/
[…] na svém blogu Älánek, ve kterém vyzdvihuje pozitivnà vlastnosti Red Hatu a navrhuje, aby nÄ›které z nich Debian pÅ™evzal. Russellovi se pÅ™edevÅ¡Ãm lÃbà myÅ¡lenka dvou vÄ›tvÃ, kdy jedna (RHEL) nabÃzà stabilitu a […]
Hello,
the brazilian CDD effort http://brdesktop.org is an interesting approach, similar to what you are proposing, focused on desktop.
Their packages are already in SID.
The cdd will track Testing each 6 months, synchronizing with Stable at release.
Regards.
Andre Felipe