[Python-Dev] Python 2.6.5

["Martin v. Löwis"]

> If a committer or triage
> person sets an issue to release blocker it should mean that they think
> the release manager should make a decision about that issue before the
> next release.  That decision may well be that it shouldn't be a blocker.

I think it's (slightly) worse. For the release manager to override the
triage, he has to study and understand the issue and then make the
decision. In the past, that *did* cause delays in releases (though not
in bug fix releases). So committers should be *fairly* conservative in
declaring stuff release-critical. The release manager's time is too
precious.

> I think that the logic here is that it is all well and good if the release
> manager has the time to review all critical issues pre-release, but since
> they may not, those with tracker privs can help sort through the clutter
> by marking as release blockers those issues that the release manager (and
> others who are helping out) really *should* think about before the release
> goes out the door.  I think that's what Barry was asking for when he said
> "feel free to mark things as release blockers".

That would require that Barry actually *can* judge the issue at hand. In
the specific case, I would expect that Barry would defer the specifics
of the Windows issue to Windows experts, and then listen to what they
say.

I'm personally split whether the proposed patch is correct (i.e. whether
asctime really *can* be implemented in a cross-platform manner; any
definite ruling on that would be welcome). In the past, we had rather
taken approaches like disabling runtime assertions "locally"; not sure
whether such approaches would work for asctime as well.

In any case, I feel that the issue is not security-critical at all.
People just don't pass out-of-range values to asctime, but instead
typically pass the result of gmtime/localtime, which will not cause any
problems.

Regards,
Martin