Re: Temporal Release Strategy
On Fri, 2005-04-15 at 21:48 -0500, Adam M. wrote:
> Unfortunately this totally changes the purpose of "stable". Stable is
Yes and no. It changes the concept of stable in that stable evolves.
You still have the static release as long as we decide to keep that
version of all the packages in the package pools. The implementation of
package pools created a virtual release environment where the release in
the archives is only defined by the contents of the Packages file at the
time of release.
> This has a few disadvantages and advantages. The main advantages include,
>
> * less time spent on maintaining your production machines - once you set
> them up, no need to change the configs.
> * ability to maintain 1000s of installations by one person - installing
> a new machine can be as simple as `dd` the partition.
> * security fixes do not break your system (3rd party applications or
> otherwise)
>
You can still have this environment. As long as your system looks at
the Packages file from the release (and the security updates Packages
file).
> The main disadvantage of this is that stable becomes stale.
>
> The current testing is a remedies for this problem. Up-to-date packages
> are provided in testing where the packages are virtually always
> production quality. The main disadvantage of testing is lack of
> environmental stability seen in stable.
>
Testing does not remedy this problem. If testing was "virtually always
production quality" then there would be no need for the release manager
to go through an elaborate freeze & bug fix cycle to get things in shape
for a release.
>
> The only difference between the support of testing vs. stable in Debian
> is security support. If we have volunteers for the security team for
> testing (for Etch), then I'm certain Debian can have two release modes,
>
Another difference is that testing will get new versions of packages and
those versions might (but should not) cause breakage. Testing has had
breakage issues in the past. Ten days is not enough time to catch all
the possible interactions (or even the majority of them). I'm also not
naive enough to think that my proposed "candidate" step will never cause
breakage. The purpose of the additional step is to have a place where
things change slower than testing to catch more of the obscure bugs that
only become apparent with more time. By requiring there be 0 RC bugs to
progress from "testing" to "candidate" and "candidate" to "stable" we
cause stable to change when the software really stabalizes, not at an
arbitrary time selected by the release team.
> We should not destroy the notion of stable to get up-to-date packages.
I'm not trying to destroy the notion of stable, I have a different
definition of stable. My definition of stable is software that does
what it is designed to do without bugs, in the manner in which the
designer and programmer intended. I'm also trying to show that the
traditional concept of a release in Debian is outdated. I will even go
so far as to say the reason Debian has had exponentially longer release
cycles is that the traditional concept of a release is flawed for a
project the size and scope of Debian. We need to adjust our thinking
outside the traditional definitions.
I think this proposal could actually enhance the stability of Debian
(where stability is defined as lack of bugs, not software that never
changes except for security updates), as well as further enhance the
reputation Debian maintains in the community.
Pat
Reply to: