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

Faster Release Cycle = More Up to date Packages...

I am *not* talking about release dates.
(Anyone who starts talking release dates from hereon will be taken 
out back and given an ice cold shower-down ;o))

Through time many people have criticised Stable Debian for having an 
extremely slow release cycle, which causes an outdated distribution 
-- even before it is released.
See [1] and [2].
Especially [3] is a good analysis of the problem.

After a handful of words I will propose a remidy to speed up the 
release cycle, as well as make Debian a current distribution -- 
without compromising Debian quality or policies, or the daily 
development work.

Debian's current problem with old packages can be seen by the fact 
that a number of vendors have reportedly dumped the current Stable 
release in favor of the Testing distribution some time ago.
That can only mean that currentness of content has become more 
important than bugs, security and stability.
It means that Debian is not in balance with currentness of contents.
Debian can not continue down that path without compromising Debians 
own policy of supporting its users.

The introduction of Testing does not seem to have helped the release 
cycle as the freeze for Debian 3.0 has been going for about 5 months, 
and there are still 68 RC bugs left at the time of this writing.
At the current pace 3.0 may be out right around May 1St 2002.
At that time it will have been more than 1 year and 6 months since 
the previous point release, which by then contains packages more than 
1 year and 6 months old.
To make things worse, 3.0 contents will at the time of release 
already be about 6 months out of date.

That is very slow and very old considering that most other 
distributions release about every 6 months, or faster.

As Debian expands, this can only get worse.


There is an issue depency list for the problem.

The main issue:
- How up to date the packages in the distribution is.

The package currentness issue is controlled by an other issue:
- How long the period of a freeze lasts before all RC bugs are fixed.

The freeze period issue in turn is controlled by a third issue:
- How long the development period is between the last stable release 
and the next freeze.

Since the currentness of the packages is controlled by two time 
factors, those two time factors are what I wil concentrate on here.

What makes up the development period between a Stable release and the 
next freeze is undefined.
It is up to the release manager to figure out when he thinks it is 
time for a new release.
Refer to the Debian Developer's Reference; Chapter 5 The Debian 
Archive; Section 5.6.1 Stable, testing, and unstable; Paragraph 4:
"After a period of development, once the release manager deems fit, 
the testing distribution is frozen..."

What makes up the freezing period is primarily fixing RC bugs. The 
more RC bugs present in Testing when it freezes, the longer time the 
freeze will last before all bugs are fixed so that Testing can become 
Stable and can be released.
Hence, the more RC bugs in Testing when it freezes, the longer the 
Stable release cycle period since the freeze adds to that period.

Shortening the Stable release cycle (Testing development period, plus 
Testing freeze period) will improve the currentness of Debian 
packages (as shown a bit further up in the Issue Dependency List.)

There is one things that we can not compromise:
Debian releases when Debian is ready.
Meaning: We do not set release dates.
(OK - Strictly, I have to go for a shower-down now ;o))

However, that does not exclude adding time management internally in 
the Debian development procedures.

One big thing that controls the number of RC bugs in Testing (and 
thus, how long time a freeze period will last) is how long time is 
between a Stable release and the next Testing freeze.
In that period, Testing is open to contributions from Unstable, and 
by and large it is therefore Unstable that introduces RC bugs into 
The longer time Testing is open to contributions from Unstable, the 
more RC bugs testing will end up with before a freeze.
This "open timeframe" defines Testing's development period.


I will propose a remidy to reduce the number of RC bugs in Testing, 
speed up the overall release cycle, and improve the currentness of 
Debian packages.

The main proposal is to introduce a fixed short Testing development 
period into the development cycle like this:

1. Feed Unstable packages to Testing for a fixed short period of time.
2. Freeze, bugfix, release.

For the sake of examples, I could imagine the Testing development 
period being defined to last for 3 months.

Since the freeze period seldomly is as long as the development 
period, 3 months of development plus freeze should add up to a  
Debian release cycle of approximately 6 months or faster.

Introducing a fixed short development period for Testing 
automatically reduces the time between Stable releases.
Limiting the time during which Testing is able to recieve RC bugs 
from Unstable (the Testing development period), should reduce the 
number of RC bugs in Testing, and thus shorten the freeze time.
The side effect is that packages in Stable Debian become more up to 

So what do we get from a fixed short Testing development period?
- More frequent releases.
- More up to date packages.
- The same quality.

It is important to see this scheme in the light of previous Testing 
development periods.
The Woody Testing development period was more than 1 year, which gave 
a lot of time for RC bugs to get from Unstable to Testing, thus 
prolonging the resulting Woody Testing freeze, thus adding to the age 
of the packages in Stable 3.0. They will be about 6 months old at the 
time of release (half a year).
The Woody Testing development period also imposed a high age on 
Stable 2.2 packages. They are now more than 1 year and 6 months old.


Please note that this proposal is simply the introduction of a fixed 
short development period into the Testing part of Debian's 
development cycle system.
It will not have any impact on any Debian policies (with the 
exception of adding the Testing development time period definition to 
the process policy), or in the way developers and users work with 

Please also note that this scheme does in no way require Debian to 
announce any release dates.
The criterions for releasing Debian are unchanged.

In previous discussions about this topic, concern has been raised as 
to whether more frequent releases of Debian would from time to time 
mean that there would be nothing new to release.
I do not believe that it would ever occur.
Unstable continues to develop parallel with Testing development as 
well as parallel to Testing freeze.
Once Testing is released as Stable, there will be plenty of new and 
updated packages in Unstable waiting to enter the new Testing.
I am thinking in time periods of 4-6 months. A lot happens in 4-6 
months, as other distributions prove.

Now it is time for your input.

Best regards
Johnny Ernst Nielsen :o)

Mention of release cycle problem on Debian web pages:

Mention of release cycle problem on Debian mailing list threads:


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: