Re: post-release package update policy

[Raul Miller <rdm@tad.micro.umn.edu>]

Behan Webster:
   IMHO the only people served by a fixed release are CD vendors.

More generally, the people served by a fixed release are those who
would be affected by race conditions over a span of several hours or
days.  The concept of a fixed release is useful in that it reduces the
entropy of the name space, in particular:

(*) users of ftpmail or webmail who may have a period of many days,
even weeks between a directory access and a file retrieve.

(*) people issuing detailed instructions on how to set up a system.

(*) html hrefs

(*) debugging obscure, yet large scale problems.  [One thing that can
happen over the life of a project is oscillating bugs where fixing
"bug a" causes "bug b", and fixing "bug b" causes "bug a".  One
solution to this problem is to have some person who is familiar with
the entire history of a project.  Another solution to this problem
involves keeping historical records.]

(*) other situations I've not thought of.

I suspect there's other ways of dealing with this problem -- but this
gets into various sorts of tradeoffs.

Fernando Alegre:
   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.  [The slow paced tree would have changes such
   as:]

   1) bug fixes
   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)

Aside from the fact that this doesn't really address the race
condition issue, I detect a minor ambiguity here: what does "work
seamlessly" mean?  What's a "major bug report"?  These questions
probably have good answers, but these aren't issues we've tackled.

I'd hate to force the debian site maintainer into making ambiguous
decisions with each package release.  This is a good way to make sure
things don't get done right and that they don't get done quickly.

Incidentally, what I'm envisioning is that at a package instance
release time the debian site maintainer do something like this:

$  followlink() {
>    perl -e 'for(@ARGV){while(-l){$_=readlink;} print $_,"\n";}' $1
>  }
$  cd /debian
$  old=`followlink stable`
$  stable=`followlink latest`
$  latest=__________________ # fill in the blank
$  cp -Raul $stable $latest
$  rm stable; ln -s $stable stable
$  rm latest; ln -s $latest latest

Or, this could be made into a shell script or perl program...

But, the big issue is: what do we want to accomplish.  I think that
the very concept of a "debian release" implies that at some point we
stop working on some version and continue future work on some later
version.

[Note, for the benefit of mirror sites, if we go this way, perhaps we
should perhaps leave the existing /debian directory in place for a few
months and move to a new /Debian directory that we manage "properly".]

-- 
Raul