[Python-Dev] Change in priority fields
Guido van Rossum
guido at python.org
Tue Mar 18 06:11:18 CET 2008
On Mon, Mar 17, 2008 at 11:49 PM, Barry Warsaw <barry at python.org> wrote:
> On Mar 17, 2008, at 11:35 PM, Guido van Rossum wrote:
>
> > What do I do for something that should absolutely go into the 2.6final
> > release (say) but is otherwise pretty minor? I've been using critical
> > to make sure it doesn't get put off until past the release.
>
> Critical is the right one to use. Neal and I will basically be moving
> issues between 'release blocker' and 'critical' with the former
> meaning this issue blocks the upcoming release. The latter means it
> will (probably) block an upcoming release. I think when we make a
> major milestone, e.g. the first beta, the first release candidate,
> etc., we'll triage those critical and move some up to release blockers.
>
> We should not release the finals until there are no release blockers
> or criticals. Either the critical gets moved to high and ignored, or
> it gets moved to release blocker and gets fixed.
Hm... This feels a bit like inflation of priorities to me; there would
be lots of critical bugs and quite a few release blockers... The
highest priority just pertains to the upcoming release which could be
weeks in the future. I'd be more comfortable if there were 1-2
priorities above that, e.g. one higher for stuff that makes a buildbot
go red (i.e. breaks a test) and two higher for stuff that affects most
developers (e.g. stuff checked in that doesn't even build).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev
mailing list