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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
