Johnny Ernst Nielsen wrote: > Debian's current problem with old packages can be seen by the fact > that a number of vendors have reportedly dumped the current Stable > release in favor of the Testing distribution some time ago. > That can only mean that currentness of content has become more > important than bugs, security and stability. > It means that Debian is not in balance with currentness of contents. > Debian can not continue down that path without compromising Debians > own policy of supporting its users.
So someone was more interesed in currency than in stability, and they swiched from the debian tree that emphases the later to the tree that emphasises the former. And what was the problem again? > The package currentness issue is controlled by an other issue: > - How long the period of a freeze lasts before all RC bugs are fixed. Wrong. You would do well to make sure you're fully up-to-date on how debian's release process is currently handled before posting half-baked critisism of it. A casual persusual of the last 10 months or so of postings to debian-devel-announce might be a useful first step. > The main proposal is to introduce a fixed short Testing development > period into the development cycle like this: > > 1. Feed Unstable packages to Testing for a fixed short period of time. So you think that dumping a large number of upstream updates of packages into testing in a very short period of time will result in a better integrated and less buggy debian. I see. > For the sake of examples, I could imagine the Testing development > period being defined to last for 3 months. As, for example, it was planned to be in between the releases of hamm and potato, IIRC. And we know how well that worked. > Introducing a fixed short development period for Testing > automatically reduces the time between Stable releases. > Limiting the time during which Testing is able to recieve RC bugs > from Unstable (the Testing development period), should reduce the > number of RC bugs in Testing, and thus shorten the freeze time. Here's something to think about. Base has been frozen for 8 months, tasks + standard have been quasi-frozen for several months, and yet we are still getting new release critical bugs filed on those sections of the distribution, on a daily basis. Why do you think that might be? > a lot of time for RC bugs to get from Unstable to Testing, thus > prolonging the resulting Woody Testing freeze, thus adding to the age > of the packages in Stable 3.0. They will be about 6 months old at the > time of release (half a year). The versions of mozilla and X in testing are not 6 months old. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]