Your message dated Fri, 4 Apr 2008 19:14:17 +0200 with message-id <20080404171417.GA1789@benz.df7cb.de> and subject line Re: Bug#31581: project: Time between releases is too long has caused the Debian Bug report #31581, regarding project: Time between releases is too long to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 31581: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=31581 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: project: Time between releases is too long
- From: Cesar.Barros@web4u.com.br
- Date: Thu, 7 Jan 1999 18:11:09 -0200 (EDT)
- Message-id: <m0zyLlt-0006vyC@cesarb1.cesarb.personal>
- Reply-to: Cesar.Barros@web4u.com.br
Package: project Version: N/A I've seen recently at slashdot complaints about the slow release cycle that Debian has. The Debian model is based on three stages: unstable, frozen and stable. However, the freezing process takes too long. For example, since autoconf 2.13 has been recently released, it will take another full year until it gets on frozen, and then another year and a half until it gets on stable - and the whole process is delayed because of some easily broken packages - like xfree86 (that seems to break once every two releases). This make packages with unimportant but neat bugfixes and new features be released slowly - thus making Debian lose its technical superiority when compared with some other distributions that release buggy packages but release often. The right way to avoid this bug of the Debian release system without losing its features would be to break the 'glue' between the core packages (essential, base, perl and anything that would confuse the whole system if broken) and the non-core packages (everything that is useful or useless but will not break the system if makes a mess). Then _each package_ would have its own unstable and stable versions. After a new version of each package is packaged, it would be put in the 'unstable' version. Then, _after it is tested with the other stable packages_ and after people say it's working (testing it with the possibly-broken unstable packages would also be good but if it's not the packages' fault incompatibilities are not an issue here), it will be considered 'stable' (and moved to the 'frozen' dist). The 'core' packages are more problematic. They should be tested as a whole, and should have the three phases: unstable, frozen and stable. In the 'frozen' state, no features should be added; in the non-core packages, this is a responsability of the upstream maintainers (if they like it that way), but in a 'core' package a 'feature freeze' is useful to avoid lossage. And finally, we need a (totally unreleated to the above) CD stage. It is more like the current setup, and should be done the following way: CD-ROM core packages stable stable stable frozen frozen (for testing) stable unstable frozen (nobody is too crazy) unstable This proposal may seem too risky (since there is less testing before the 'stable' state), but consider what we face today (in the main dist): - An outdated stable - A frozen with some packages that are quite stable and some badly broken because of some misdone bug fix; - An unstable with some packages that should be on stable (since they fix some bad bugs of those 2-year-old packages) and some totally screwed packages that need more testing. A user then faces a dillema: use the stable but outdated software or the more recent (and generally better) software mixed with totally broken packages? Some might consider using a mixed setup, but not only this is hard but has some sutble problems since the unstable packages are misdesigned to the 'unstable' dist, and even harder if you like dselect. We need to move from the present setup (too CD-based) to one based in multiple dists, using fully the potential power of the Internet. And with a faster development cycle (release early, release often), we can have even less bug and more cool features due to Linus's Law (read The Cathedral and the Bazaar). I know nobody is perfect, and I may have missed something. This is intendend to cause comment, discussion (and the ocasional flame war) and help to improve Debian (and beacause it's cool to install a new version of your favorite software knowing it will work ;-) ). -- System Information Debian Release: 2.0 Kernel Version: Linux cesarb1 2.0.34 #2 Thu Jul 9 10:57:48 EST 1998 i386 unknown
--- End Message ---
--- Begin Message ---
- To: 31581-done@bugs.debian.org
- Subject: Re: Bug#31581: project: Time between releases is too long
- From: Christoph Berg <myon@debian.org>
- Date: Fri, 4 Apr 2008 19:14:17 +0200
- Message-id: <20080404171417.GA1789@benz.df7cb.de>
- Mail-followup-to: Christoph Berg <myon@debian.org>, 31581-done@bugs.debian.org
- In-reply-to: <m0zyLlt-0006vyC@cesarb1.cesarb.personal>
- References: <m0zyLlt-0006vyC@cesarb1.cesarb.personal>
Re: Cesar.Barros@web4u.com.br 1999-01-07 <m0zyLlt-0006vyC@cesarb1.cesarb.personal> > I've seen recently at slashdot complaints about the slow release cycle > that Debian has. The Debian model is based on three stages: unstable, frozen > and stable. I think we are well on the way of fixing this, so I'll close this bug. :) Christoph -- cb@df7cb.de | http://www.df7cb.de/Attachment: signature.asc
Description: Digital signature
--- End Message ---