Re: Temporal Release Strategy
On Mon, Apr 18, 2005 at 04:24:34PM -0500, Adam M wrote:
> A similar thing is already here in http://snapshot.debian.net/
Similar only in that they have daily snapshots. Vastly dissimilar in
that what is provided is the complete archive, bugs and all.
I'm not saying we call each day a release, but we allow stable to be
updated from candidate daily and call it a release when a particular
event happens. That event is to be defined outside the process of
the archive evolution.
>
> You cannot do this with the archive. The current archive size is
> already too big for most mirrors to handle.
>
I don't believe this would add a significant amount of material to the
archive. If the software in candidate is stable, the only time a
package is different between candidate and testing is during the three
month test period. Archive size needs to be addressed, and will most
likely continue to be a problem for some time to come.
> > 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.
>
Yes, bugs are part of each and every package. The trick is in knowing
what bugs are present so you can deal with them. The longer you test,
the greater the chance that a critical bug which requires an unlikely
sequence of events to trigger will be discovered.
> > > 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.
>
I would argue that it depends on which particular version of emacs you
are using as to if it should be called mature and relatively bug free.a
If you are pulling the latest CVS snapshot I would not call that mature
or bug free. If you are using a version that has been released for some
time, then it is possible to consider it mature - the bug free part is
another story. Mature != bug free. Stable != bug free.
Mature can mean "feature rich" or "old" and stable can mean "unchanging"
or "of sufficient quality for the intended purpose."
> > 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/
I am proposing a progressive update to stable, so we can declare a
collection of packages (with their associated version numbers) a release
by a well defined rule. Once a release is declared, you have what you
termed "interface stability." I am only proposing time based snapshots
in that you could, on any given day declare what was in the stable
Packages file to be a release, and it could contain different packages
than the previous release.
>
> 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!
If there were 30 uploads of apache, over 36 months, there would not have
been any updates to the candidate package as none of the updates were
old enough. This is he point of the 3 month time to discover bugs.
If a security fix is needed, we only are fixing the last few versions
that made it to stable - given your scenario at most two versions.
>
> Also, try providing an efficient stable security build daemons! The
> chroots would have to be rebuilt for each package.
>
Again, this need is addressed by the requirement that the package meet
the rules for promotion. The challenge would be little different than
it is today.
> > 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.
If RC bugs are found so quickly in unstable, why has there been no
release in the last 3 or so years? Testing is normally quite usable.
That is part of the reason I believe this type of approach to releases
would work.
Pat
--
Patrick Ouellette
pat@flying-gecko.net
kb8pym@arrl.net
Amateur Radio: KB8PYM
Reply to: