El mié, 05-01-2005 a las 04:16 -0800, Stephen Birch escribió: > Paul van der Vlis(paul@vandervlis.nl)@2005-01-04 14:40: > > Hello, > > > > One of the biggest disadvantages of Debian for me is the long time it > > takes for a new stable version. > > I guess one man's meat is another man's poison. > > Since I administer a large number of distant computers I view the long > time between stable releases as a feature not a bug. > > > What about saying something like: the next stable release comes in the > > beginning of 2006? > > Once a year works for me, but any more frequent would be a pain in the > neck. Frankly a release every 18 months seems about right. I agree with you on this. People using stable can not cope with upgrades each 6 months or so. > > > I can understand something like "Debian releases when it's ready", but > > many people have to work together. Maybe it's better to say: "a package > > releases when it's ready, but the deadline for the next Debian release > > is a fixed date". > > Also the concept of "releases when it's ready" seems to be a little > contrived. When *what* is ready exactly? The current system of > defining a release seems to involve identifying a number is arbitrarily > characteristics that will define the new version. The release occurs > when they are complete and the RC bug list is low. > > Perhaps a date based release mechanism could be built using a new > distribution, call it prestable. > > Packages qualify to be enter prestable after residing in testing for > ten days and having NO RC BUGS. The idea is to keep prestable in a > highly stable state at all times, a rolling stable if you will. > > So a package follows the following path: > > unstable --> testing --> prestable --(approx. 12 months)--> stable > > People running servers (like myself) will stick with stable. Those > wanting a reasonably stable system but want the latest features run > prestable. Those wanting the very latest but don't care about RC bugs > run testing. Developers normally run unstable. > > In some ways prestable would resemble the current stable when the > release manager has begun freezing it. But here lacks how packages migrate from testing to prestable. Is this a snapshot of testing at, lets say 12 months with 6 months for checking it, or does packages migrate following soe guidelines as they do right now from unstable to testing? > > Of course one would not want prestable to be released with critical > components missing. To prevent such a thing a number of packages are > identified as release essential (RE). Every RE package > has to have migrated from testing to prestable for the annual release > to take place. > > Any non-RE packages with RC bugs at release time simply do not make it > into the stable release for that year. If it looks like a critical > package will be ommited the release manager can always make that > package RE. Ok, that is nice for RE packages. But how other packages would be handled? Without an aggressive removal policy, they can take longer for being ready that the release time. Of course, it is supposed that testing doesn't have RC bugs, but you know that is not always true. > > Although the target is for an annual release to occur, the proposed > mechanism also permits the project to identify a set of features for > the new release. For example, had prestable existed for 3.1 the new > installer would have been listed as RE. > > So ... Debian would still release "when its ready" but everyone has a > better idea of what "ready" means simply by looking at the RE package > list. Why don't you put this idea in Debian Wiki? (http://wiki.debian.net/?ReleaseProposals) Thanks. -- Jose Carlos Garcia Sogo jsogo@debian.org
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente