Re: Bits from the Release Team - Kicking off Wheezy
On 28/04/2011 17:30, Raphael Hertzog wrote:
> On Thu, 28 Apr 2011, 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.
>
> First, the beginning of the development cycle is no longer so clear cut.
> You take the release, but we could just as well consider the freeze as the
> start of the new developement cycle because development can continue and
> won't end up in the next stable release.
>
> It's clear that testing will have higher number of RC bugs than the new
> stable but they should not be the same. Because any RC bug fixed in frozen
> should really be fixed in unstable at the same time (and the BTS version
> tracking ensures we don't miss them).
>
> It just means that we already see RC bugs that we would have only
> discovered a few months later if testing/unstable had been frozen.
> So in the end it means we have more time to discover and fix RC bugs
> that are going to affect the version of Debian.
>
That's not really guaranteed. I don't know on which fact this is based on.
>> 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.
>
> No, only updates of packages which have been affected by a transition or
> packages which have had a newer upstream version in unstable will have to
> go through that route. The percentage of affected packages start at 0%
> the day of the freeze and grows slowly during the freeze. (You can still
> use britney on top of unstable during the freeze)
>
So, we will have a britney running between testing and frozen. (I guess).
Also, we try to accept only packages with a small diff during the freeze.
If the rolling idea is implemented, contributors would be concentrating on
introducing new stuff in unstable, that's really *new*. I'm pretty sure
that the diff won't be as small as we require it to be during a freeze.
So, all in all, we will have to use t-p-u really more often.
> And even when $codename-proposed-updates has to be used, there are cases
> where it's possible to take the fixed source package in unstable and just
> rebuild it in $codename (packages without new upstream versions but which
> have fixes and have been entangled in a transition). Even if it's
> recompiled in a different environment, it's still better than receiving a
> completely untested package.
>
Again, with rolling implemented, I'm not sure you'll be able to do it à la
Ubuntu way. You'll have to select a patch from the whole diff, and apply
it and then upload to t-p-u. In this case, it really depends on what kind
of changes were introduced. You might see funny stuff happen with that
patch applied, without the rest of the diff. Remember that we live in the
Rolling world, where contributors continue to do their developement during
the freeze, where new versions are introduced, where it's not obvious that
you'll find manpower of motivation to fix an old version when you're in
the middle of a transition happening…
>
> That said, I would gladly also experiment other ways to reduce the length
> of the freeze. Do you have ideas?
>
You want a constantly usable testing, but are you working these days on
fixing RC bugs affecting testing? Don't get me wrong. I'm not
finger-printing. I didn't find time to do that myself. But, if we all try
to do that, things will be much more simpler (welcome in "bisounours" world).
Last bits of the Release Team announced a perpetual 0-day NMU policy. I
think that it's a good move to encourage contributors to fix more RC-bugs,
even if we are not frozen (yet). I have the feeling that no-one read that
announcement…
[1] http://lists.debian.org/debian-devel-announce/2011/03/msg00016.html
> Mine is that officially supporting testing means that more maintainers
> will start to care about RC bugs in testing and will fix them sooner (i.e.
> not wait for the freeze to do it).
>
We really don't need to wait for that to encourage contributors to care
about RC bugs in testing. Zack did a great job with his “Release Critical
Bugs of the Week” (RCBW) [2]. That's another great idea that could enhance
testing's state. Why not start to fix RC-bugs today? until the next
freeze! Why adding a new suite to force people to fix RC-bugs in testing?
(Uh, yes… it's the pretty matches what you said, but expressed explicitely).
[2] http://upsilon.cc/~zack/hacking/debian/rcbw/
To summarize, You can start fixing RC-bugs that affect testing right now!
What are you waiting for?
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,debian.org}
Reply to: