[Martin von Loewis] > Now that there are only ten days left for the release candidate, I > wonder whether there are any release criteria beyond "builds on > Windows". Sure. > 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. Yes, that's part of The Plan. > Looking at the remaining bugs, we see > > Priority 8: two reports (assigned to loewis and nobody) The "nobody" bug is sprintf -> PyOS_snprintf conversion; it's not assigned to anyone in particular because 3 people in PythonLabs have been working on it. > Priority 7: 11 reports (6x akuchling, 3x gvanrossum, > 1x jackjansen, 1x fdrake) > > 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. Me too, although it's the Distutil (akuchling) bugs that seem most at risk. Note that I just boosted one of the regexp bugs to priority 7 (/F, are you there?). Guido returns from paternity leave tomorrow, so PythonLabs will triple its available manpower then <0.9 wink>. > That seems to suggest one of the following alternatives: > > 1. Move the deadline for the release candidate, Possible, but at this time I think it's unlikely. > 2. Lower the priority for some of the reports, Most likely, for the Distutils and Mac-specific bugs (no, we're not going to hold up the release just because the "copy" menu command on a Mac-specific console window isn't enabled). > 3. Move the threshold for release-critical bugs (to, say, 8), No. > 4. Give up the notion of release-critical bugs No.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4