Bug#31581: project: Time between releases is too long
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
Reply to: