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

Bug#31581: marked as done (project: Time between releases is too long)

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

31581: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=31581
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
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 ---
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. :)

cb@df7cb.de | http://www.df7cb.de/

Attachment: signature.asc
Description: Digital signature

--- End Message ---

Reply to: