Re: Bits from the Release Team - Kicking off Wheezy
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.
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…).
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.
Now, IMHO, #1 is a sad thing and a pity. #2 is crucial during the freeze
period. and #2 and #3 might imply longer freeze period. The fact that we
"start the dev cycle with the new stable" and that "sid and testing are
used to test the future stable" is what makes the quality of our stable
releases outstanding! (IMHO).
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".
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?
¹: Well, you can't say no since "rolling" *is* "testing" :)
²: No, 3 months isn't 25% of $dev-cylce > 1y.
> There are other possible changes but I want to discuss them separately
> because even without those changes, the testing without freeze is a
> worthwhile goal in itself.
>
> Still, since you seem to insist, here are ideas I'd like to
> investigate:
>
Well, you asked us to comment on your proposal…
> - reduce the set of architectures required for migration to testing to
> i386/amd64/armel and have buildd of other architectures prioritize
> missing builds in testing over missing builds in unstable (freeze
> should be enough time even for slow arches to catch up and FTBFS on
> already release architectures is still RC)
>
It depends on the architecture (the ability to catch up)… but I'll let
this question to wb-adm folks.
> - be less strict and keep old binaries (and thus 2 versions of the
> same source package) in testing. This applies in particular for
> libraries going through SONAME changes and which can happily coexist
> during a transition.
We do that already for big transitions (examples are ffmpeg and openssl).
The next Gnome transition will need something like that for some libraries
too.
> Re-enable the strict requirement a few months before freeze, and get
> rid of the old binaries/versions during freeze (eventually dropping
> any package which has not been updated if required).
>
We don't forget about old binaries when the transitions is done. We keep
working on reducing the number of reverse dependencies to zero to be able
to remove the old binary. It worked quite well up to now.
> - allow/encourage usage of t-p-u to rebuild unstable packages that are
> ready to transition except for the fact that they are entangled in a
> transition
>
In most cases, we can workaround this doing some britney hinting when some
pacakge is needed but has an RC-bug (it's rare though). When it's
entangled in a transition, we try to get the transition done quickly.
But, I agree that we can make use of t-p-u more often, when needed. Except
that it's not needed everytime… and it's mostly relevant when the pacakge
fixes an RC bug or security bug. ymmv though.
> - have different level of RC bugs: there are RC bugs that are
> acceptable in rolling that are not acceptable in stable, I'm thinking
> in particular of FTBFS (and even more for FTBFS which affect non-common
> architectures)
>
But that's saying that some architectures are more important than others.
And Debian doesn't (yet) prioritize an architecture over another one. If
an architecture is largely lagging behind, it becomes obsolete and we try
to find for it a new place. Ensuring the same level of quality among all
the architectures is the Debian way… I'm not sure that we can get
concensus on this change. icbw though…
>
> Do not confuse those ideas with the current discussion to introduce
> rolling as a non-freezing testing.
>
As said above, the idea is to introduce a "frozen" suite, and this has as
side-effect a non-freezing "testing" :)
Regards,
--
Mehdi Dogguy مهدي الدڤي
mehdi@{dogguy.org,debian.org}
Reply to: