Since I first became involved with Debian (1997 ish), people have complained about the slow release cycle. This has caused me to draw the conclusion that there will always be someone who complains about the frequency (either slow or fast) of official releases. BACKGROUND COMMENTARY: The advent of testing and package pools held the promise to shorten the release cycle and improve the stability of the Debian stable release. The debate can rage on in other circles as to the success or failure of that statement. There may be another way. The institution of package pools has essentially reduced the concept of a release to a package index file generated on a particular day. As long as the packages listed in the Packages.gz file are available in the package pool, that Packages.gz file describes a "release." The "release" may not be stable, and may contain many RC bugs, but it is a definite, reproducible collection of packages that can be installed. The automated progression of packages from unstable to testing has made testing a viable distribution for many users. That is not to say testing is suitable for all users and all tasks, but rather that testing is frequently "stable enough" for many uses. I will venture to say the promotion process from unstable to testing is an unqualified success. PROPOSAL FOR DISCUSSION: I suggest we can eliminate the traditional concept of a "release" with the addition of another step in the progression from unstable to stable. Additionally, all promotion of packages from one step to the next will be automated according to strict rules. The progression I see is: unstable -> testing -> candidate -> stable The existing rules for promotion from unstable to testing continue to be used. Promotion from testing to candidate requires meeting the same rules as promotion from unstable to testing with the following exceptions: packages must be in testing for at least 3 months, and have no release critical bugs. Promotion from candidate to stable would follow a similar pattern, with a time in candidate requirement of 3 additional months. Security updates are then provided for packages for 36 months after they have been replaced with a newer version in stable. No changes are made to experimental. CD image generation can be run from any stage. I would suggest monthly image creation from candidate, and quarterly generation from stable. For purists who insist on "blessing" a collection of packages proven to work together with a release name & number, they can be satisfied if we "release" driven by content changes (new libc, new desktop, whatever) instead of the calendar. Pat -- Patrick Ouellette pouelle@debian.org pat@flying-gecko.net kb8pym@arrl.net Amateur Radio: KB8PYM
Attachment:
signature.asc
Description: Digital signature