Re: post-release package update policy
David Engel writes ("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.
That sounds like a reasonable approach. It's the approach taken with
the Linux kernel, another distributed programming project, and it has
worked well there.
> 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.
Fine.
> 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!
When I have a spare moment I shall post my view of how we should do
the transition from our current `elf-as-optional-extra' scheme to
having many of the system's critical binaries depend on 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.
There is no problem with people going to the distribution site every 3
to 6 months and saying `download-and-upgrade'. Whether this will work
doesn't depend on the project having decided to snapshot at that
point. Of course, if we do what David Engel is suggesting they'll
probably find it wasteful to download everything unless there has been
a new instance of the release cycle.
My collection of packages is very patchy. I haven't been upgrading
continuously. You'll see that I occasionally report bugs in
out-of-date versions of packages (my fault) or in packages that depend
on newer versions of others but fail to declare the dependency.
If I'm the maintainer of the packaging software and I don't feel the
need to keep up with the stream of continuous upgrades I don't see why
the users think they need to :-).
I think there may be a certain misperception by the users, that
someone is saying they *have* to upgrade when a new version is
announced on debian-changes (or shortly afterwards). This is simply
not true.
Raul Miller writes ("Re: post-release package update policy"):
> [...]
> The snapshot concept is good for people who for, whatever reason, need
> a stable image to work against for some period of time. This is
> axiomatic for a distributed system. Yes, this keeps old bugs around
> but that's not the only consideration.
I can see that snapshots could be useful for some people, but what we
are considering is whether their presence needs to be organised by the
project and its ftp archive. If someone just wants a snapshot of our
stable release tree (say for making a CD-ROM) they can download one.
I don't think we as the people developing the software need frozen
snapshots. Having a stable tree where only bugfixes happened would be
good.
brian white writes ("Re: post-release package update policy "):
> [...]
> The discussion is about a "release of packages". There is little problem
> with staying on the "latest" stream of released packages, but it is
> generally felt that periodically a group of latest (or near-latest) packages
> be frozen that anybody could install from scratch and be assured of it
> working. This release would also become the cd-rom release, etc. From
> there, users could upgrade packages constantly from the "latest" directory
> or just when a new release is frozen. Again, it's not necessary, but
> it would be convienient.
It is not necessary to forbid all package updates merely to ensure
that people can install from scratch and get a working system.
Philip Tuckey writes ("Re: post-release package update policy"):
> I would like to add my vote in favour of there being a fixed set of
> packages (I mean including the base) which constitutes the most recent
> "release" or "version" of Debian. This is so that new users can go to a
> specific place and get a set of packages which are quasi-guaranteed to
> produce a working system. (The current continual evolution does not often
> lead to incompatibilities/new problems, but it can.) [...]
David Engel's proposed stable tree which only gets bugfixes provides
this too. We don't need to cast the release in stone.
> [...]
> I also believe that for the public face of Debian (and otherwise) it
> would be useful to be able to refer to a specific "release" and for that
> to mean a well-defined set of packages. (Otherwise any numbering scheme
> does not have the conventional meaning at all.)
Linux kernel version numbers increase very rapidly. I don't even know
what the most recent 1.3.x is. And there you go - I just said 1.3.x,
which doesn't have an existence of its own, but is nevertheless a
useful concept. I can see Debian 0.93R6 meaning approximately the
same as Linux 1.2.x (within context, of course). Just because there
is no one thing you can point to that is Linux 1.2.x doesn't mean that
it isn't a useful concept.
Dale Scheetz writes ("re:post-release package update policy "):
> [ regarding why we need a "Release" ]
> Because, Behan, some of us do not yet have either a Debian system or a big
> pipe onto the internet to get one! Some of us are creaping crawling slugs on
> the belly of the earth, but we still want a Debian system!
>
> Look I know this issue has ramifications for mirror sites, CD makers, and
> developers. But, if you want to attract new people to Debian, you need to
> have "A Product" that we can come and get, not a constantly changing
> collection of packages.
>
> I appologize if I sound a little cranked up but I am.... :-}
Why is a collection of packages that is continuously updated not "a
Product" ? You can download it all in one go or in dribs and drabs,
and if we are careful about what we update - as we should be - then it
will work regardless. The advantage to you is that you get a less
buggy system.
alegre@mars.superlink.net writes ("Re: post-release package update policy"):
> Here is another suggestion. I don't think it is neccesary to have a
> completely frozen tree. What we should have is both a slow-paced and a
> fast-tracked trees.
> [...]
> Two types of packages should still go into [the slow track] tree:
>
> 1) bug fixes
This is, I think, what David Engel was talking about.
> 2) packages which work seamlessly with the rest of the packages in the
> "stable" tree and which did not have major bug reports for the last 6
> (six) months. (or some other reasonable amount of time)
>
> So this tree would still be a moving target (that's the advantage of the
> net as opposed to static media) but upgrades would occur at about every
> six months, so people would have plenty of time to download everything.
I don't know what the feeling is about this one; I think it seems
reasonable, but people may disagree. How do we tell whether a package
does work seamlessly with the rest of the packages in the "stable"
tree ?
Ian.
Reply to: