Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/11 at 16:52 +0200, Mehdi Dogguy wrote:
> On 28/04/2011 15:52, Raphael Hertzog wrote:
> > On Thu, 28 Apr 2011, Mehdi Dogguy wrote:
> >> | before | during | release | freeze | freeze
> >> | day+1 | dev period | |
> >> ——————————————————————————————————————————————————————————— | sid
> >> | sid | sid before | testing | testing (frozen)
> >> | testing==stable | stable | stable | stable
> >> ——————————————————————————————————————————————————————————— | sid
> >> | sid | sid after | testing | testing |
> >> testing | stable | frozen | frozen (new stable now) |
> >> | stable | oldstable
> >> ———————————————————————————————————————————————————————————
> >>
> >> Is this what you have in mind?
> >
> > Yes (except you missed oldstable in the cell "before / release
> > day+1").
> >
>
> Right. It's not important for our discussion though. But, you're are right.
>
> >> How's rolling different from testing? (except that testing freezes
> >> from time to time… yes, I know, that's the main point of the
> >> proposal, but still, I want to know if there are other changes).
> >
> > It's not different.
> >
>
> Then I have a few remarks. I wrote them earlier today, but then wondered
> if my table was correct… So, I kept them in a private draft:
>
> Philip mentioned some problems with this approach, which are listed below.
>
> 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.
That's true. But the counter-argument to that is that, since new
packages will get some testing in rolling, all the new and broken stuff
will not land in unstable at the same time, and we won't end up with 800
RC bugs in testing 3 months after the release like we have currently.
Also, with more users of testing/rolling, there will be:
- more pressure to keep testing/rolling in an usable state at all times
- more bug reporters
That should help reduce the duration of freezes.
> 2) During the freeze, you're killing an important step in the Release
> process which is "the testing". Packages that move from sid to testing are
> tested by a huge user base (sid users), and then double-tested by testing
> users. Problems are seen in sid first and stopped from migrating if there
> are issues. During the freeze, we try to avoid using
> testing-proposed-updates as much as possible, because fixes that are
> pushed through t-p-u are not tested enough.
That is based on the assumption that the sid users base is larger than
the testing user base. Do you have hard numbers about that? I've often
seen obvious important bugs only get reported when the package reaches
testing, while the bug could easily have been found in unstable.
> We really try to use it when
> it's really not possible to go through sid. And, it's too late when the
> t-p-u fix lands in testing because it might require some work to get
> things fixed again (if it has some regressions ; if it breaks other
> packages ; etc…).
>
> 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.
... but they are tested once they reach testing.
To rephrase your points, I think that they boil down to "Users that
currently use "testing" during freezes will be tempted to use "rolling"
during freezes, so "frozen" will get less testing."
I agree that it's a problem. However:
- we are likely to get more "rolling"+"unstable" users than the current
"testing"+"sid" users, so "rolling" release will get more testing
until the freeze.
- even at the beginning of a freeze, "frozen" is likely to be of
higher quality than "testing" at the beginning of a freeze. We might
encourage users to upgrade from stable on non-critical machines
earlier.
- we could encourage "rolling" users to switch to "frozen" at least for
some time, since it's a good way to help get a better Debian stable
release.
> So, your proposal isn't really about "rolling", that's just changing the
> name of something that exists already. It's not new. What's new is
> "frozen"! The fact that testing will never freeze is just a by-product of
> frozen being used to create the future stable.
>
> And as Phil said, it requires adding a *lot* of people on "frozen" to make
> this viable.
>
> I *think* that advertising your proposal as "frozen" will make things
> clearer for everyone, and reflects better where change is done.
>
> Having that said, I do agree with Zack when he says that advertising it as
> "rolling" might have a positive effect on our users. But, okay, that's a
> matter of asking FTP-folks to add a symlink "rolling → testing".
I agree that advertising the change as the introduction of "frozen"
makes a lot more sense for developers. But for the general public and
for potential users, it's the rolling release that should be advertised.
>
> But, let's go back to the original problem. We want something to use for
> everyday, that works, that's mostly stable (not in the sense of "stable
> release" but rather "doesn't have much issues"), etc… Testing works¹, and
> works great (IMHO). A lot of people want a testing suite that never
> freezes. And your proposal is one way to get that done. There are other
> ideas though. The real problem (and the obvious one) isn't the freeze… but
> rather its duration! We have to try to make freeze periods shorter.
> If the freeze lasts² two or threee months, it's not a big deal… the freeze
> becomes quite a burden when it lasts six months. We don't care (almost)
> about the number of RC-bugs during the dev cycle… and that's one of the
> issues that cause longer freeze periods. Why not working on this side?
If the freeze lasts a few weeks or a month, it's true that it's a
limited problem even for a rolling release. But three months already
sounds like a very big deal to me.
- Lucas
Reply to: