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

Drop testing

#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

Ein Bauer zwischen zwei Advokaten gleicht einem Fisch zwischen zwei
		-- Sprichwort

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


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

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

Reply to: