Re: post-release package update policy
I've been trying to stay out of this discussion for the most part, but
their are a few points that either aren't being brought up or need to
be repeated. Since Ian's post is the most current and touches on
everything I want to say, I'll pick on it. :-)
> Clearly we need both a `stable' and an `experimental' system.
That seems to be what I'm hearing.
> However, bugs in the `stable' system will continue to be found, and
> will have to be fixed. We must therefore not cast the `stable' system
> in stone.
>
> We should therefore make the stable vs. experimental distinction on a
> per-package level too.
>
> Packages should initially be released into the experimental system,
> and then when the particular version has proved stable we can move it
> into the stable system.
>
> This will not, of course, deal with interdependencies between
> different versions of different packages. However, that problem can't
> be solved by snapshotting the release, either: a snapshot would simply
> have all the bugs that were present at a particular time.
>
> We should deal with version dependencies by having package maintainers
> think carefully about interrelationships before asking for a version
> to be moved into the stable tree. I don't think there is any way we
> can arrange for this problem to solve itself: we will have to put
> thought into these issues every time they occur.
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.
> The worst disadvantage is that neither would be suitable for use - the
> frozen tree would be full of bugs that were fixed in the updates
> tree, and the updates tree would be full of broken packages with good
> versions in the stable tree.
This is why you try to restrict yourself to only fixing bugs in the
released version -- you minimize the risk of introducing new bugs with
new features.
BTW, most reasonable customers/users can accept minor bugs, especially
if they are documented with suggested work-arounds. It is only the
serious bugs which need to fixed immediately.
> I was under the impression that debian-0.93 (aka debian-current) was
> going to be the stable copy, and that debian-1.0 was going to be the
> experimental version (which would presumably start out with a.out
> versions of everything and gradually move to ELF).
>
> Perhaps we need three trees, a stable a.out, an experimental a.out
> and an ELF ?
I really only see a need for two trees -- one stable a.out and one
experimental ELF. IMO, the experimental a.out tree should only be a
short-term repository for bug fixes to be checked out by developers or
beta testers before going into the stable tree.
BTW, I've been very patient and tried not to complain about how long
this a.out release is taking. However, has anyone else noticed that
Debian is now the only major Linux distribution that has not converted
to ELF? I haven't seen it publicized much, but even Linus has switched
to ELF!
> We have a very powerful modular approach to system integration - let's
> not throw that out of the window by insisting on arbitrary flag days
> and snapshots and the like.
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.
David
--
David Engel Optical Data Systems, Inc.
david@ods.com 1101 E. Arapaho Road
(214) 234-6400 Richardson, TX 75081
Reply to: