Martin von Loewis writes: > 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) 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. > 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), 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. > 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). I agree we should keep the concept. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
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