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

Re: Bits from the Release Team - Kicking off Wheezy

On 28/04/2011 17:25, Lucas Nussbaum wrote:
> On 28/04/11 at 16:52 +0200, Mehdi Dogguy wrote:
>> 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

"new rolling"? (and you seem to use "testing" in the next sentence).
(I really think that we should forget about "rolling" for now… since it's
confusing even for you)

> 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

having it usable and having a low number of RC-bugs are completely two
different things. (IMO)

> - more bug reporters

*iff* we get "more users of testing/rolling".

If you add more suites, you'll get less bugreports in one of them¹. Then,
you may argue that we are more interested on a subset and not all of them.
But, we try to keep the same level of quality for *all* of them.

¹: It's the same kind of assumptions that "we will get more users". Yes, I
can also say "we will get less bugreports for frozen".

>> 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.

It's based on the assumption (if we consider that the proposal has been
accepted and applied) that we won't have a big number of users of
"frozen"… which is quite a problem. That would be true at least for the
beginning of the cycle.

>> 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.

In the new scenario, they'll be testing when they reach "frozen". What I'm
arguing here is that we will have less users of frozen, than we used to
have for 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."

or using rolling everytime. why should they use "frozen" if rolling still
fits their needs?

> 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.

"rolling release"? do you mean "rolling suite"?

> - 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.

at the beginning of a freeze, "frozen" is created from "rolling". How's
that different from "testing"? That's based on the assumption that we will
have more rolling users, more bug reporters, more… and poneys.

> - 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.

We encourage the contributors to do a lot of things during the freeze. I
never saw those recommandations followed. tbh. Do you intend that users
are better citizens than contributors? (ok, semi-joking :)) Do you think
that users follow closely what's happening in Debian?

TBH, Until last January, I had some friends that were not aware that we
were frozen. (fwiw, they are testing and stable users).

>> 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.

Yes. But, we are still on -devel, not on -user, and not even on
raphaelhertzog.com… ymmv though.


Mehdi Dogguy مهدي الدڤي

Reply to: