Re: Bits from the Release Team - Kicking off Wheezy
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.
> 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. 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…).
Yes, my answer to that is that we must get more users to enable t-p-u and
test packages there as well.
See http://raphaelhertzog.com/2011/04/28/no-freeze-of-debian-development-what-does-it-entail/
for a more detailed answer and related suggestions to limit this problem.
> 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)
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.
> 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?
The introduction of testing was supposed to reduce the length of the freeze.
It did not work as planned, I think we really need a 3 to 6 month freeze to get
to the quality level that we want to have.
That said, I would gladly also experiment other ways to reduce the length
of the freeze. Do you have ideas?
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).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Reply to: