[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from me

Martin Loschwitz wrote:


For one, of course one problem is that the software we distribute in the
Debian release which is called 'stable' is quite too old to be useful for
anyone who needs current desktop software. It would be absolutely, and if
I say absolutely I mean absolutely, necessary, to fix this situation. If
there is one instance inside of Debian which has this duty, then it is up
to us to create something which gives the user more actual software while
not being completely unstable.

Problem: Software in "stable" is too old.

While this is definitely a problem, it strikes me more as a symptom of some larger, deeper problem. I think it would be useful to explore why exactly the release cycle is so long, in the interests of speeding it up for desktop users.

I see a few possibilities. Note that I'm not a Debian Developer, these are just thoughts that I've gathered from following Debian for a couple years.

1. The release cycle is designed that way.

I don't think this is the real cause of the problem. Debian has always released "when it's done". Since we're not on a time-based release cycle, it doesn't seem like it's in any way inherently designed to be so long.

2. There are too many packages to certify stable before release.

This can be seen in the number of RC bugs still currently open for Sarge. With over 12000 packages, getting them all working together, and working well is a huge job, even for the number of DDs working on it. I don't think the answer here is to restrict the number of packages in Debian. The beauty of it is that it encompasses just about every OSS software package out there, making it extremely easy to add something to your system if you want. One solution could be to split the release cycle into "core" and "extra" sections. The "core" would be the main Debian repository, shrunk to just the most important base packages (kernel, gcc, libs, perl, xfree86, etc.). The "extra" repository would be a fluid distribution, updated with packages compiled and certified for use in the current stable "core". This would be similar to the current Woody + backports scheme we have now, except that the backports would be done in an official supported manner.

Another solution could be a three-part process: "core", "extras", "updates", or perhaps "stable" and "updates". The stable release would occur as it does now, consisting of "stable" or "core" and "extras". The seperate "updates" repository would contain certified updated software for use on the current "stable" release. Servers and other machines that require absolute stability simply wouldn't use the "updates" repository. The main stable release cycle would stay slow, but the "updates" repository would hold current backports to the current release.

3. There are too many architectures to sync at the same time.

This can be seen in the problems faced by XFree86 4.3, which just entered unstable yesterday (or today). The solution here would be to split the main release into sub-releases: 3.1 i386, 3.1 ppc, 3.1 alpha. This would have the effect of causing different architectures to get out of sync with each other, though, so probably wouldn't work for the main release. It could, however, work for a possible "updates" or "extras" repository.

Anyway, those are just some ideas to toss around. I don't think a seperate Debian-Desktop distribution is the answer, although I don't see any reason we couldn't make and host our own "updates" repository.

If anyone's wondering, Martin's idea for a time change is ok by me.

Joel Konkle-Parker
Webmaster  [Ballsome.com]

E-mail     [jjk3@msstate.edu]
Phone      [662-518-1636]

Reply to: