Now that there are only ten days left for the release candidate, I wonder whether there are any release criteria beyond "builds on Windows". 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. Looking at the remaining bugs, we see Priority 8: two reports (assigned to loewis and nobody) 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. That seems to suggest one of the following alternatives: 1. Move the deadline for the release candidate, 2. Lower the priority for some of the reports, 3. Move the threshold for release-critical bugs (to, say, 8), 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). Regards, Martin
[Martin von Loewis]
Sure.
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.
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.
Martin von Loewis writes:
The one assigned to me really must be fixed before release. There are a number of people who use the indexes, and they can be the only effective way to use the affected documents much of the time.
The one assigned to me is at priority 7 because that would block the release. Shift the threshold up and I shift the priority of that bug to match.
I agree we should keep the concept. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
And on Linux. :-)
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.
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.
Nah. --Guido van Rossum (home page: http://www.python.org/~guido/)
Don't forget the patches too. Although I've only just skimmed them, it looks like all the patches are at priority 5, most likely because they haven't been triaged. I'll try to do a quick scan through the unassigned patches. -Barry
[Martin von Loewis]
Sure.
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.
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.
Martin von Loewis writes:
The one assigned to me really must be fixed before release. There are a number of people who use the indexes, and they can be the only effective way to use the affected documents much of the time.
The one assigned to me is at priority 7 because that would block the release. Shift the threshold up and I shift the priority of that bug to match.
I agree we should keep the concept. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
And on Linux. :-)
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.
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.
Nah. --Guido van Rossum (home page: http://www.python.org/~guido/)
Don't forget the patches too. Although I've only just skimmed them, it looks like all the patches are at priority 5, most likely because they haven't been triaged. I'll try to do a quick scan through the unassigned patches. -Barry
participants (6)
-
barry＠zope.com -
Fred L. Drake, Jr. -
Fredrik Lundh -
Guido van Rossum -
Martin von Loewis -
Tim Peters