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: