[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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?).


[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: