[Python-Dev] Release criteria

[Guido van Rossum]

> Now that there are only ten days left for the release candidate, I
> wonder whether there are any release criteria beyond "builds on
> Windows".

And on Linux. :-)

> In particular, I think that the release candidate should not be
> produced until "critical" SF bugs have been resolved. In #420851,
> Barry indicates that bugs with a priority higher than six will block a
> release. This sounds reasonable.

I still abide by this rule.

> Looking at the remaining bugs, we see
> 
> Priority 8: two reports (assigned to loewis and nobody)

Yours is for BSDI, a tiny minority platform.  You set the priority
yourself, meaning you want to fix it before the release candidate.
But if you don't fix it, I'd rather lower the priority to 6 than hold
up the release.

The other is the sprintf thing -- I believe that's been addressed, at
least to a sufficient degree to warrant lowering the priority.

> Priority 7: 11 reports (6x akuchling, 3x gvanrossum, 
>                         1x jackjansen, 1x fdrake)

I plan to address mine (I'm coming back to work Monday).  Fred already
promised to address his.  Andrew has a whole bunch of distutils and
setup.py bugs assigned.  I'm not sure that these should be allowed to
hold up the release -- there just doesn't seem to be anyone at
PythonLabs who has the expertise to fix them, and frankly, I don't see
these bugs as release showstoppers.  So maybe their priority should be
lowered -- although I'd prefer to keep them at the current priority,
in the hope that when Andrew (or someone else) finds some time, they
know which bugs to address first.  That is, assuming that all the
priorities have been assigned rationally, which I'm not so sure of.

I think Jack desperately wants to fix his bug in time -- that's why he
raised the priority.

> Given that the oldest of these reports is from 2001-07-30, I think it
> is unlikely that they will be all resolved within ten days. That seems
> to suggest one of the following alternatives:
> 
> 1. Move the deadline for the release candidate,

Unlikely, unless we find a real showstopper (none of the above count).

> 2. Lower the priority for some of the reports,

Might do.

> 3. Move the threshold for release-critical bugs (to, say, 8),

No way.

> 4. Give up the notion of release-critical bugs (which I would regret,
>    since I hope "my" prio-8-bug should be fixed; it'll just take
>    some more days).

Nah.

--Guido van Rossum (home page: http://www.python.org/~guido/)