[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: post-release package update policy

>>>>> "IanJ" == Ian Jackson <ian@chiark.chu.cam.ac.uk> writes:

IanM> Some suggest that it would be best to leave debian-0.93 alone after
IanM> the release, and that instead of moving new and updated packages
IanM> into debian-0.93, we should put them in a different (but
IanM> easily-accessible) tree, such as debian-updates-0.93.  The
IanM> advantage of this approach is that it gives users access to both
IanM> the "released" and completely up to date distributions.  The
IanM> disadvantage is that users would have to make a decision as to
IanM> which of them to install.

IanJ> The worst disadvantage is that neither would be suitable for use
IanJ> - the frozen tree would be full of bugs that were fixed in the
IanJ> updates tree, and the updates tree would be full of broken
IanJ> packages with good versions in the stable tree.

It would be a disadvantage unless a part of the installation process
is to sweep through the updates directory and check for crucial
updates; if the user is not connected to the network, a warning
message to double-check the crucial-updates list seems adequate.

As for security, it seems to me that if Debian coordinators really
want to take responsibility for security issues, a new minor release
should be made.  Please keep the namespace clean!

IanJ> We have two trees, stable and experimental.  Each contains a
IanJ> particular version of each package.  We should not decide which
IanJ> version of each package to put in the stable tree merely by
IanJ> release date of the package in question. 

Why not?  Are you recommending that debian maintainers and package
developers/maintainers be second-guessed?  I think all the latest
versions should go into the current release.  It is far more scalable
to make it the responsibility of a package maintainer and debian
maintainer to think about problematic system interactions -- not
debian release coordinators.  Coordinators should review problems
when they come up and *coordinate* a solution.

IanM> Others suggest that we should keep doing what we're doing now--that
IanM> is, as packages are released, we should move them into debian-0.93.

I advocate getting rid of the concept of "debian-stable".  I think it
is just fine to accept that the "debian-experimental" will have
some bad interactions, and that many people will prefer to use it in
spite of this.

I advocate this organization:
  1.  An absolutely frozen read-only snapshot of the last release.
      Heck, mount it on a CD!!
  2.  An up-to-date tree.
  3.  A machine-readable set of crucial fixes to the frozen snapshot and
      programming parts to make this installation automatic.
      This may involve adapting the latest version or the last 
      frozen version of a given package.
IanM> The advantage of this approach is that users are guaranteed to have
IanM> all fixed and updated packages at the time they download the
IanM> distribution.  The disadvantage is that a release of Debian
IanM> GNU/Linux becomes a constantly moving and shifting target instead
IanM> of something tangible.  Alot of people complain that this is a
IanM> major problem with how we make releases.

Well, system administrators around here laugh at Linux.

IanJ> We definitely need two complete copies of the distribution, one
IanJ> with the latest bleeding-edge of everything, and one that has
IanJ> the latest stable version of each package modulo all the
IanJ> versions in it working together.

I mostly agree.  Although it begs the question as to why a release
needs so much modification.  The changes ought to be small and be able
to be _applied_.  Having a complete copy of the stable distribution
suggests to me that a release is a trivial matter, and that a person
might as well just go for the latest versions.

IanJ> Perhaps we need three trees, a stable a.out, an experimental
IanJ> a.out and an ELF ?

a.out and ELF can co-exist just fine.

IanJ> We have a very powerful modular approach to system integration -
IanJ> let's not throw that out of the window by insisting on arbitrary
IanJ> flag days and snapshots and the like.

I don't see how having a frozen, named, versioned thing is
in any way contrary to the modular approach.  Simple metric:
as soon as N packages or N megabytes are updated from the last
release make a new minor release.

Reply to: