[Python-Dev] Python 2.6.5

["Martin v. Löwis"]

Antoine Pitrou wrote:
> Martin v. Löwis <martin <at> v.loewis.de> writes:
>> IOW, I feel that release blockers should only be used if something
>> really bad would happen that can be prevented by not releasing. If
>> nothing actually gets worse by the release, the release shouldn't be
>> blocked.
> 
> I think most blocking bugs we've had had been existing for a long time, but had
> only been discovered or at least reported quite recently.
> Other blockers were also about features not yet implemented, or missing
> backports. So whether something would have "gone bad" is really in the eye of
> the beholder :)

Maybe I'm being pedantic, but I really think there should be more
objective criteria for such things. We could set a policy that we don't
want to release Python if there are known ways of crashing it, but I
think that would be useless as it would mean that we can't make any
releases for the next five years or so (because we all know of ways of
crashing the VM that aren't fixed yet; when I run out of ideas, I just
ask Armin Rigo :-).

So the policy that I would suggest to follow instead is that known
crashes (and other "serious" bugs, like incompatibilities, or failures
to build) can block releases only if they are regressions, or if the
release manager decides to make them release blockers.

In particular, I think that requests for blocking a release should be
accompanies with a promise from a committer to resolve the issue by some
point in time. When that point has passed with the issue unresolved, the
release manager should be free to unblock the release.

Regards,
Martin