Re: New stable version after Sarge
On Fri, Jan 07, 2005 at 12:50:04AM -0800, Steve Langasek wrote:
> Yes, I don't think the release team has any intention of working
> itself ragged to get a second release out 6 months after sarge. I
> also don't think there's any consensus among developers (or users)
> that we *want* to release Debian that frequently.
Well, the development model in Linux (Free Software, OSS, whatever) is
such that new hardware is supported in new releases. A commercial OS
vendor does introduce support for newer hardware in older releases of
their OS (I remember several cases of this on IRIX for example) via
patch revisions or point releases or whatever they might want to call
that. But this is a time-consuming task and most upstreams prefer to
just release a new version. This is not always true of the kernel,
that's right, but it's common in XFree86 and I have to assume that it's
also the case for X.org. It's also true of things like GPhoto, or
Gimp Print. Upstream does not want to waste time doing point releases
of older software. People might argue that you "just" need to shift
the load to the Debian maintainer. For security updates, yes, I can
agree with that, but for "normal" updates, no, sorry.
That means I do think that *users* have some interest in this kind of
thing. Backports.org? No, that doesn't cut it. It's got to be
officially supported by a release and on the install CD.
Branching stable for this purpose (just like security updates) is not
an option IMO. I don't think we have the manpower for this.
> A 6-month period honestly doesn't allow us much time for new
> development anyway.
It depends on what you call development. Are you thinking of "<Big
Thing> has a release cycle that's not compatible with a 6 month release
period"? Say GNOME or KDE? Well, <Big Thing> gets in the next
release. So simple. We are known for missing upstream releases by a
hair (sarge is almost certainly going to miss the next upgrade to
GNOME, perhaps to KDE, it's already missing X.org, gcc 3.4 is subject
to debate) so this wouldn't put us in a worse situation than now.
Are you thinking of say, the installer? I certainly *hope* that the
installer is going to stay in the current status for at least another
release! Another "whoos, let us restart from scratch" won't be
welcome by anyone. And my hope is based on the fact that the new
installer is *good* (instead of just adequate, like b-f).
Or is it the next big thing going on with the archive?
We don't have to go from X.0 to (X+1).0 in 6 months. It's perfectly ok
to go from X.0 to X.1.
> If all we wanted was a point release of sarge, that'd be fine; but I
> think most people would like to see etch be an improvement over sarge
> in more respects than just hardware driver count, and we have to be
> realistic that this means a period of heavy changes followed by a
> period to stabilize everything again.
And *that* was our mistake with sarge. By introducing *many* heavy
changes we burned ourselves out. These changes are very welcome, don't
get me wrong. But I say it again: this is pushing our testing users
away. Thanks to broadband there are many who are happy with "testing",
but let's face it: for a very long time, it was a major risk to use
testing and it had a _load_ of software that was either buggy or
suboptimal, and the fixes were already present in unstable for a long
time. I dumped testing on the machine I used to use on a daily basis
around 2002 because it was a pain. Some people say this has improved
since then, but if the kind of big changes that stalled testing back
then happen again, well, it's back to square one.
Ok, 6 months may be too fast for some people (and I still want to know
about concrete examples where this is true and why), how about 9
months? How about 1 year? My point is: set a goal and try to
accomplish it.
Marcelo
Reply to: