Re: wheezy postmortem re rc bugfixing
On 2013-05-09 00:48, anarcat wrote:
> [...]
> In fact, I am of the opinion that we should relax the requirements that
> the release team systematically review every diff posted during the
> freeze, especially if the freeze is going to last almost a year... That
> always seemed to me to be an insane amount of work.
>
> [...]
>
> A.
>
FTR, I believe "we" (i.e. the RT) never wanted or aimed for a freeze
taking a year.
I can see how your idea might seem attractive for maintainers, you can
get that fix in you just missed or upstream has a fix and don't have to
cherry-pick from a lot of other changes.
That said, for the former, the freeze date was announced a year ahead
of time. Yet, there were quite a few maintainers that seemed to be
caught by surprised by the freeze. If you add that "slush" period, I
fear maintainers would just be even more "relaxed" (because "I can
always fix it during the slush").
To be honest, I am not convinced that people are vigilant enough to
avoid doing ABI breakages, so a "slush" upload might end up starting a
transition[1].
What I would like to see is a way to reduce the need for changes post
freeze. It was my understanding that "time-based freeze" was intended
to do that - by letting "you" know ahead of time so you could have your
things ready (before last minute).
The execution of the time-based freeze might have failed. Also,
"testing" did not serving its purpose of "always being in (a
near-)releasable state"[2] with its 500+ RC bugs at the start of the
freeze was not ideal (either?).
~Niels
[1] During the Wheezy development cycle we did have quite a few
uncoordinated library transitions. Combine that with some people's
"acceptance of huge diffs" post-freeze...
[2] At least it is my understanding that this is why "we" (i.e. the RT)
wants testing around. Admittedly a lot of people seem to expect it to
be a "rolling" distribution instead.
Reply to: