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.
Regards,
--
Mehdi Dogguy مهدي الدڤي
http://dogguy.org/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4db99028.5020...@dogguy.org
