On 4/16/05, Patrick Ouellette <[EMAIL PROTECTED]> 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
