Faster Release Cycle = More Up to date Packages...
NOTE!
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.
---THE PROBLEM---
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
Testing.
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.
---THE SOLUTION PROPOSAL---
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.
Repeat.
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
date.
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.
---IMPORTANT NOTES---
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
Debian.
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)
[1]
Mention of release cycle problem on Debian web pages:
http://www.debian.org/vote/2000/leadership_debate/joel-speech
http://www.debian.org/vote/2000/leadership_debate/informal.txt
http://www.debian.org/vote/2000/leadership_debate/transcript
http://www.debian.org/vote/2002/platforms/branden
[2]
Mention of release cycle problem on Debian mailing list threads:
http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg00199.html
http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg01262.html
http://lists.debian.org/debian-devel/2002/debian-devel-200201/msg02494.html
http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg01653.html
[3]
http://lists.debian.org/debian-devel/2002/debian-devel-200202/msg01069.html
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: