In Debian: Election campaigns and release cycles chimaera brings up the idea of security support for Debian testing to make testing a viable (i.e. secure) distribution for desktop usage. Actually this is already underway as can be seen from here.

The current state of the next Debian release nicknamed Sarge has been the cause of quite some clamoring and whining, and I must admit that even though I have been using unstable for some years now and thus am not directly affected by releases, I am getting annoyed by the Sarge release procedure even if it is just because I think it puts Debian in a bad light. Even the fact that it has been 31 months since the last release (Woody) isn’t my main point of contention, but it is the fact, that the release date got moved further and further. If I remember correctly the first planned date I heard was something about the end of 2003 (!), at which point I jokingly commented, that my best guess would be somewhere in the middle of 2004.

Don’t get me wrong: Rushing Sarge now won’t do any good. If Sarge is released it needs to be of the best possible quality and absolutely rock-solid so it lives up to the expectations of stability Debian users have come to love. But something needs to change. Whatever that may be…

So far I have seen three ideas how to alleviate the situation:

• Reduce the number of architectures from 11 to 4 which then only cover the most important and widespread architectures (namely i386, IA64, AMD64 and PPC). The other architectures will only be available as repositories but will not see official releases.
• Provide security support for testing. This would make testing suitable for everyday desktop use without having to worry about unpatched holes but one can still have up-to-date packages, which is the main problem of the Woody release for Desktop machines today
• The Debian Volatile Project. This project aims to provide updates for the stable distribution for packages which tend to get out of date relatively quick, like e.g. virus scanners, spamassassin et al.

These three ideas all take different directions and are aimed at solving different symptoms of the underlying problem. Reducing the number of architectures would certainly reduce the workload for a release and in my opinion has the best chances of getting at the root cause of the problem. Security support for testing would neatly solve the problem of “stone age software” for desktop users while still providing a (semi-)tested and fairly stable environment. From the discussions and help at Debianforum.de I gather that even for a beginner running testing on a desktop is a pretty feasible solution. The Volatile Project is clearly directed at production servers and clients in large (corporate) installations. It does not provide the newest software but enhances the stable platform with the most needed updates, so one does not have to use inofficial backports. In these environment predicatbility, stability and consistency are of paramount importance which is why testing with security updates may not be an option.

So in conclusion to my little writeup I would like to see all of the three options mentioned above to succeed in one way or another, because in my opionion this would really improve the value of Debian for everyone from desktop user to corporate sysadmin.

Patrick

This entry was posted on Friday, March 18th, 2005 at 14:15 and is filed under FOSS. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.