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: