[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits from the Release Team - Kicking off Wheezy

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

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

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

Attachment: signature.asc
Description: Digital signature

Reply to: