Mehdi Dogguy wrote: > There are other issues I want to mention here (you may judge them as > minor, but let's see): > > 1) At the beginning of the developement cycle, (with the new plan) you > start from testing, and not the new stable. So, you don't start with a > base that's rc-bug free, or at least, as polished as the new stable is. > > 2) During the freeze, you're killing an important step in the Release > process which is "the testing". > > 3) All updates to frozen have to be made through > $codename-proposed-updates. That isn't great because we don't test fixes > uploaded there hard enough.
I agree about all three of these being bad problems with the rolling proposal. Another problem is that testing can be frozen in stages, which allows development from unstable on eg, leaf package to continue on filter into testing until relatively close to the release. Rolling could disrupt that, since uploads to unstable targeted at rolling would disallow easily getting the same uploads into testing (or frozen, or whatever you call it) once the two have diverged. So, much effort would need to be doubled. And at the same time, having a non-frozen rolling release available during freeze time could easily distract people from working on testing/frozen at all, because a shiny rolling release that they and some users can use is still available. I am unhappy during the current choke point of testing being frozen, but that choke point does serve as an incentive for the whole project to work in the same direction: toward actually getting a good stable release out. It's my feeling that rolling is mostly a distraction from making testing constantly usable. It appeals to DDs because we're the main sufferers during the freeze. To most users of testing, a 5 month period when it doesn't update as much, but is also more constantly usable is mostly a draw; that period is when testing has the most new users. At best, the idea can make a constantly usable rolling release available for the N more months out of every 18 month release cycle. (In the last release cycle, N was approximatly 5 to 6 months.) We have a long stretch of time until the next freeze during which rolling won't be a benefit at all -- why start on it now? Why not work on improving testing's usability during this time, now that the intial post-release rush is (mostly; gnome excluded) over? I do agree that "rolling" is a nice name for promotional purposes. I would certianly not object to a rolling symlink, for propotional purposes. If testing can be made appealing and usable for more users, then great. And if testing has a lot of users, and lots of work being put into making it constantly usable, that will influence the rest of the project, including the release team. And as Mehdi points out, it could well shorten the freeze time too. -- see shy jo
signature.asc
Description: Digital signature
