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