Re: so what? Re: Debian development modem
I think my suggestion about (1) focusing packaging maintenance on
the current release while doing system upgrade development separately,
and (2) setting up package release mechanics which provide `released',
`proven', and `unproven' package release stages fits well with the
following:
On Sun, 31 May 1998, Anthony Towns wrote:
<snip>
> [three sorts of user, rearranged, with trimming and extra comments:]
>
> > > The first group wants to always have the latest of everything, regardless
> > > of testing level or absolute stability.
>
> ....who don't require any special testing, but do want daily updates or
> similar.
Those really living on the bleeding edge keep current from the developmental
tree for the next-release system.
Those wishing to be buffered from system development instabilities but
wanting new packages as soon as they are released update from the current
debian system release tree, the `unproven' subtree. This is where package
maintainer releases show up. Bugs reported by these users can keep a buggy
package from advancing into the `proven' subtree.
> > > We think the [second] group represents the primary target market for a
> > > distribution like Debian. This group has good net access, wants to stay
> > > reasonably current, but can't tolerate dealing with the worst 10% or so of
> > > the package churn that happens in a bleeding-edge "unstable" tree.
> > > They would prefer not to bump into any real problems, but they're willing
> > > to stumble once in a while if that's the price of keeping up with security
> > > patches, new development tool releases, and the like.
>
> ....who don't want anything common to break [like grep only working on
> stdin, for example], and thus need a buffer of the first sort of users
> between them and the latest release. They'd like irregular updates, so
> that packages wouldn't get more than a month out of date, say.
These update from the `proven' subtree. Bugs reported by these users can
eliminate a buggy package from the `proven' subtree and/or keep it from
advancing into the `released' subtree.
> > > The [third] group is CD-focussed. They are either folks who aren't on the
> > > net with lots of bandwidth, or who are using Debian to provide the platform
> > > for other work, and don't want to be "bothered" by constant change.
>
> ....who don't really want anything to break that could have been fixed,
> and who don't really want updates more than a few times a year [once
> every six, four or three months, say].
These update from the `released' subtree.
Note that the `released' subtree has its minor version number incremented
with each new release (picking up new & updated packages from the `proven'
subtree). Thus, for example, different CD offerings of debian 2.0.3 would
be identical, even if mastered separately by different CD manufacturers on
dates several weeks apart. The `proven' and `unproven' subtrees would
not be release-numbered, and snapshots taken on different dates would
likely differ from one another.
CD manufacturers having a release cycle shorter than our cycle of minor
releases could offer ever-later snapshots of the `proven' and `unstable'
subtrees on CD releases pressed for the same debian minor system release
version.
<snip>
> Since it seems to be the current trend, I'm going to throw in YA
> suggestion on how to rework the distribution process.
<suggestion snipped, but paraphrased and addressed below>
This, as I understand it, concerns managing releases from what I have called
the developmental tree above. That is, the tree where development of the
next system release is going on.
As I understand it, this would apply release mechanics there similar to
what I have suggested above for the ongoing package releases for the
current production debian system release. The development system would
be stabilized at some plateau, and a frozen snapshot of the system at
that stage of development split off. Development would then continue
in the unstable development tree to the next plateau.
> Packages could only be moved to "frozen" after being static in "unstable"
> for a week or so, and with no release-critical bugs filed against them
> and with the release manager / the testing groups permission.
My suggestion would be to have the developmental tree use the latest
packages released to the `unproven' subtree of the production release.
Maintaining inter-release compatibility would be a priority for the
system development team. Inter-release compatibility would be broken
where necessary, but efforts would be made to avoid this. Development
plateaus would not be concerned with the package mix, but rather with
some intermediate level of next-system-release development having been
reached.
If the new system release involved a new libc release, the new libc and
related development tools would be put into place and tested. Backwards
compatibility with old-libc packages would be maintained. The new
system would proceed to release with development tools using the new
libc by default, but with most packages on the system still using the
still-supported old libc. This, then, becomes the production system where
package maintenance is focused. In a series of subsequent minor system
releases, then, individual packages would move from the old libc to the
new libc.
<snip>
Reply to: