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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
