#include <hallo.h>
> > Some improvements have already been proposed by Eduard Bloch and
> > Adrian Bunk: freezing unstable while keeping testing.
>
> Jerome, please, you could have asked me. I prepare an internal GR draft
> for exactly this issue, but it is to be made public on the day of the
> release, and better not before. We should concentrate on making the
> Sarge release ready, NOW. Do not start another flamewar.
To hell with it, the avalanche has already started.
The attached paper was written down as a GR draft, but if the problem
can be solved peacefully by a consens on d-d and in agreement of the
release manager(s), this is the way to go. Otherwise, take it as a real
GR draft which should be completed later.
It may sound a bit radical, but core points have been mentioned in the
thread already. I suggest to do it in a more radical way:
- unstable lockdown in the freeze
- drop Testing and concentrate on work instead of wasting time on
synching stuff. This eliminates the need for testing-security. See
the last part of the paper for details.
- about the "filtering updates for frozen" - yes, some additional
manpower is required but that work must be done. The problems with
Testing synchronisation are not of pure technical nature, they are
social problem, and so they should be solved by people and not
scripts.
Regards,
Eduard.
--
Ein Bauer zwischen zwei Advokaten gleicht einem Fisch zwischen zwei
Katzen.
-- Sprichwort
ABSTRACT
--------
I propose that the Debian project resolve these questions:
- should we continue using Testing and the gradual freeze model?
- should we change the freeze model to the tristate model (similar to the one
from the old days)
Possible choices:
- stop using Testing distribution and change to the Tristate freeze model
- stop using Testing, the release manager should develop the freeze model
- continue using the current release model
RATIONALE
---------
Why is testing bad?
==================
One of the first and most known things: it puts a lot of outdated packages on
the head of our users! Yes, testing sounds like a good compromise for people
that want to have bleeding edge software without taking the risk, but we saw in
the past years that testing created more problems that it was really worth.
The only advantages guaranteed by its structure was a promise to keep an
installable set of packages. Which does not promise a useful/bugfree piece
of software. I think we should be fair to our users when we tell them to
report bugs - we should tell all of them that reporting bugs in Sarge is
often duplicated work because the problem has been fixed in Unstable. I
think we should be fair to our users - we should not put a lot of buggy
software onto their heads (promising some bogus stability at the same time),
without having working security upgrade system. Without giving the
individual developer a chance to fix bugs in the development distribution
quickly enough. Without having automatic ways to integrate an update into
every arch in the Debian distribution.
Some words about the history
============================
Some years ago and before almost a half of developers joined, Testing did
not exist in its current form. Instead, the release cycle worked differently
(see below). At some time point, the RM of those days decided to make an
experiment, which resulted in what we call Testing now. In the years before,
the Freeze was a real freeze (not the ice sludge we have today). Unstable
was frozen as-is and stayed in this state untill the RC bug count was down
to zero. It was not worse than what we have today: Frozen got its own
release branch name, deliberate uploads to Frozen could be detected easy and
inspected by the RM. Almost the same work that is done now by the RM team.
But OTOH the developers had to eat the dog food [1] and there were no stupid
overhead required to move packages to Testing, working around obscure
problems.
How does the situation look today?
==================================
Debian Testing is not stable and is not mature. It is full of shitty bugs
(let me define this term as name for ugly bugs that bother the users but do
not look appear as critical for maintainer, or not important enough to touch
package in the holy "frozzen" state). Such bugs are a disaster, they make
our definition of a Stable release absurd. Yes, Debian Stable has become a
buggy stable release. Just face it.
The major goal (making Freeze periods shorter) was not reached. The second
goal (faster releases) was not reached. The third goal (better software
quality in the development branch) was not reached, at most partially (the
users did not have to deal with PAM bugs this time, hahaha).
So in my eyes, the Testing experiment failed and should be finished. Now.
So how would the removal of Testing help?
=========================================
- there would be no obscure criteria that tell maintainers to held back
package upgrades
- it would eliminate the need of "testing build daemons". Instead, the free
resources could be used to implement exprimental buildd, for example.
- Debian's development branch would be more secure
- the release date would be more predictable (assuming that there will be
active FTP masters) and faster
- frozen would have better software - more up-to-date upstream versions with
less ugly upstream/packaging bugs
- maintainers would actually be forced to fix
- there would be no or less bug reports about obsolete versions, leading to
less confusion and less work for both, maintainers and users
- the users that actually want fresh software, get fresh software with
Unstable. We saw that Testing has (in average) also a large number of
problems so there is no point in having two development branches with
different bugs and no good way to deal with bugs in the other one. Yes,
users would benefit from bugfixes that reach them immediately instead of
5..90 (or more) days later The other kind of users that are used to wait
that long new (and stable) software can switch to replacements, see below.
How does the alternative plan look like?
=======================================
We should not fork a new Testing distribution before this GR is trough.
Release managers are asked to wait. If we decide for Testing, it will be
forked as they plans currently look like. If not, Testing will be no more.
When the next freeze time comes, it will be a hard freeze. Panic uploads will
always be there, but this time the avalanche will be started only once, not
with every phase of the "gradual freeze".
Alternative for the developers: Tristate freeze model
=====================================================
A possible future model for the release cycle and freze method will be so
called Tristate freeze model. It consists of three states:
- PRE-FREEZE, 2-3 Weeks before the freeze day. A frozen directory is created
on a dedicated machine and release managers can start testing the freeze
management scripts. Release team and few selected users should have access
to this resource. This testing environment is not stable and may (or not) be
purged before the main freeze begins
- MAIN FREEZE: takes three weeks, beginning from the freeze day. Unstable
branch will be moved to "frozen". Packages uploaded to "frozen" or
"unstable" are mapped to "frozen-candidates" and are to be reviewed by the
release team.
- DEEP FREEZE: 1-2 weeks. Only important updates are allowed to be moved from
"frozen-candidates". Release team has to decide with majority about this
actions.
- After the release, the contents of "stable" are synchronized with "unstable"
and the new iteration begins.
Alternatives for the users
==========================
The users will be told to switch to the following alternatives:
- Ubuntu Linux [2]. It is a good, Debian based distro and implements, what
many people expected from Testing. It has motivated developers behind so it
should never reach the bad state in which Testing, again and again.
- Debian stable with backports. High quality backports of Sid packages became
very mature in the last months, and if the release times become shorter
after Testing is away, it should become an acceptable solution. volatile.d.o
is another good step in that direction.
[1] http://www.joelonsoftware.com/articles/fog0000000012.html
[2] www.ubuntulinux.org
