[Python-Dev] Change in priority fields

[Guido van Rossum]

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/)