Re: Temporal Release Strategy
On 4/16/05, Patrick Ouellette <pat@flying-gecko.net> wrote:
> 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.
A similar thing is already here in http://snapshot.debian.net/
You cannot do this with the archive. The current archive size is
already too big for most mirrors to handle.
> 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).
see above link :)
> 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.
All you are proposing is another testing-like stage. Bugs would
propagate there regardless. Bugs are part of stable as well.
> > 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
Then your stable never existed. All software has bugs be it Linux or
Windows based Software of any complexity without any bugs does not
exist. For example, look at the number of bugs in emacs, yet, I would
consider the software mature and relatively bug-free.
> 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.
Why? Why is there RHEL 2.0, 3.0.. Why not just RHEL 2005-01-01,
2005-01-02, etc..? The releases are there to provide interface
stability. Everyone does this. What you are proposing is the time
based snapshots which are already available on
http://snapshot.debian.net/
Now, if you want to support snapshot of Debian with 36 month security,
well, be my guest :) In the last 36-months, there were about 30
uploads of Apache to unstable. Now, if only 15 such versions
propagated to stable snapshots, then you find a remote hole, and
suddenly you have to backport a security fix for 15 versions of
Apache!
Also, try providing an efficient stable security build daemons! The
chroots would have to be rebuilt for each package.
> 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.
In many ways, current testing is your stable. Extending the testing
period from testing to your proposed candidate and then stable would
do nothing about normals bugs. RC bugs are usually found quite quickly
by people using unstable.
- Adam
Reply to: