release cycle
It seems to me that the problem with the current release mechanism is
the observation that each package have very different rates of
changes. Compare active development effords to mature packages (like
the kernel or KDE vs. gawk, ed or ls).
Consider if each package had 3 stages (unstable, frozen, stable) and
that there is some sort of procedure or policy (to be determined) for
a package to move from on state to the next. Say, only a frozen
package that is bug free may proceed to stable. New features may only
be added to unstable. But in general leave it up the maintainer to
promote a package.
A stable release would be a snap-shot of all the stable packages.
Perhaps requiring a data, such as stable_1999-01-08. Per definition
of stable, that's the best we can do.
Traditional releases hamm/slink/potato would be reserved to things
like (major) libc conversions or ELF -> ELF++.
Problems:
* traditional mirror programs will not work well with this,
as one update would prompt it to mirror up to 3 files.
* not compatible with current practises (some code has to be written
and some ppl. will be displeased).
* no release annoucements
* no central control of what "stable" is
* upstream updates will have to go through the release cycle
Advantage:
* (potential) faster package turn around.
* all stages of the packages will be on the maintainer's mind
(who is really updating their hamm packages? E.g. check out
proposed updates). Isn't it the hamm users that are coming from
windows and that we should give a good start?
* blame for no-show will be directed to package maintainer(s)
which can make a difference (release coordinator cannot really).
* cd retailers will love us as they can decide how often they
want to relase the "all new" Debian Stable. This might also
lead to more mirrors.
I hope this is not a reply. Any thoughts? Feelings? Flames?
/Allan
--
Allan M. Wind Phone: 781.938.5272 (home)
687 Main St., 2nd fl. Fax: 781.938.6641 (home)
Woburn, MA 01801 Email: wind@freewwweb.com (home)
Reply to: