Granual release proposal
Preface: I can see the flames forming now, and this proposal is far from perfect, but it is a start.
Proposal: A more granual release process
Problems seeking solutions:
1. The whole distribution must stablize at once.
2. Freeze time caused by 1
3. new upstreams can take over a year to make it to stable, see 1
4. no modularity
Solution:
Now that we have package pools, we can revise the release process without large effects on archive size. I would propose creating new sections for major subsystems. Major groups of packages in their own section can then be stablized as a section (against the current stable base) and released. Since most of the time the testing and stable branches of a section are both compiled against the current stable base, users should be able to follow testing for only those section they are interested in.
I could see the following sections being useful (by no means exhastive):
base, xwindows, kde, gnome, network, dev, sound, misc.
The release cycle would thus work like this.
All sections would normally be being compiled agaist the current stable base. When a section is ready to be release (that section's testing meets release criteria and the maintainers of packages there feel it is ready), its packages are moved into that section's stable. Main will then be updated, since it is simply a collection of all stable sections. Debian announces a new minor release! This process doesn't impose any new packages in the archive, it just involves more directories and a few Packages.gz files.
When a new base is approaching release condition, an announcment will be made to give all other sections a chance to be tested against the new base. When the new base is stablized we have a new release, however, we then wait until all sections are functional against this new base before releasing. Debian announces a new major release.
Modularity is somewhat achieved by this scheme (not completely since it would take to many sections to reduce dependency to a oneway tree structure). It does provide incentive to keep bugs down, since there is no longer the "oh, I don't need to worry about bugs in my unstable packages until release," Also, it solves the common complaint of out of date software. True, the base system (kernel, libc, compilers, etc) will not be helped much by this scheme, but other systems like xfree, kde, apache, samba, etc will be able to stay up a bit better, since on a new samba or apache release, the interested parties only need to stablized the network section, for instance.
This could be fazed in after woody is released, by allow sections to be formed (efforts must be made to control the number) and as released update stable (aka woody). A base section would be formed to start the slow process of preparing for the next major release, while other sections are released.
Andrew Lenharth
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: