In <[EMAIL PROTECTED]>, David Engel wrote: > [...] > How many of you have done release management? The classic way I've > always done it is to freeze features, test it, fix bugs, test it again > and then release it. After it's released, the only changes you make > are to fix serious bugs. That means absolutely NO NEW FEATURES are > introduced into the released version except under extreme > circumstances. That also means that some bugs go unfixed until the > next release. All new features go into the working, development > version for inclusion with the next release. > [...] > In our case, we are very close (I hope) to the initial release. After > we release, we need to use restraint (something we have yet to master) > and only fix bugs in the released versions of packages. All other > changes go into the working, development versions only. Now, I know > our cause is complicated by the fact that we are largely dependent on > upstream packages that don't always come in nice, clean, bug-fix > versions, but we need to at least try to stick to only fixing bugs. > [...] > I think it's great that Debian can be upgraded incrementally and > frequently. In fact, it's one of the reasons I switched to Debian as > I like staying close to the bleeding edge. However, I'm hearing that > there are a good number of users who don't want to keep checking for > new packages every day or week. They only want to upgrade everything > at infrequent intervals, say every 3 to 6 months. I think we can > satisfy both classes of users. > I also have done release management in the traditional manner, but I don't believe that is appropriate for Debian.
I think it's clear that two classes of users need to be provided for: those who like the current method, and those who need periodic snapshots of all packages having some level of stability. The former folks share adequate, cheap Internet bandwidth. The latter group includes those folks packaging Debian media distributions and users without adequate, cheap Internet bandwidth. These are the people who need Debian "releases". I propose Debian releases consist of merely baselining the SOTA (state of the art) directory every 2 - 4 weeks. The person(s) responsible can determine the exact time to do this based on close communication from all package maintainers regarding current robustness of their packages. These baselines would be SOTA snapshots whose relative stability would be accessed after the baseline. Major feature changes whould be given major release number changes, but would still be the coordinated SOTA snapshot of the cycle, followed by the the first "maintenance" snapshot in 2 - 4 weeks. Now folks who need 1 - 2 weeks to download Debian can just grab the shapshot they want. They can then use dftp to keep their systems as current as they want. Redistributors can press full baselines in a timely fashion using a common release nomenclature. Also, for those existing Debian users without Internet access who want to stay SOTA, they could provide the non-cumulative changes from the previous release, possibly on a very small set of floppy disks. User dialog would establish relative desireability of the releases. Redistributors using long release cycles could choose which SOTA snapshot to press based on their own value-added QA. The only drawback I see is the disk space requirement for multiple snapshots would be greater for FTP sites, depending upon how long releases are kept online. The releases would not be changed after baselining! If serious problems are found, they are corrected in the next release, and everyone learns to avoid the bum release. But the release image is the same in all instantiations -- this would need to be axiomatic. This argues for biweekly releases, while resource requirements may argue for a monthly cycle. The Debian approach to maintenance is superior to all others. Potential users must be educated early about the theory of upgrading and strongly encouraged to procure adequate, cheap Internet bandwidth as part of their effort to install and use Debian. But I believe this approach to releases can enable the linkless to still obtain reasonably timely releases and upgrades in a homogeneous fashion and control how quickly they upgrade their packages.
