Re: post-release package update policy
In <9510250327.AA24805@dan.ods.com>, 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
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.