[Python-Dev] Change in priority fields

[Guido van Rossum]

On Tue, Mar 18, 2008 at 8:39 AM, Barry Warsaw <barry at python.org> wrote:
> On Mar 18, 2008, at 12:11 AM, Guido van Rossum wrote:
>  > 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 want a very simple roundup query that I can consult during the
>  release cycle to know whether everything's fine, or whether I have to
>  start pestering people and pull the big red "STOP RELEASE" button.
>  Critical gives us a priority for things we really need to fix, but
>  maybe not right this second.

Sure. My (mild) concern is that (a) the terms chosen sound a bit
alarming, and (b) there's no term left for even *more* alarming
issues.

I also want to express my concern that this sounds like a bit *too*
automatic and draconian. The key goal here (well, mine in any case :-)
is to manage developers, not to get releases out at all cost. Even
though the release schedule is set in stone, I think we should send
out a variety of reminders ahead of each scheduled release, and these
reminders must come from a human, not from a bot. There should be some
kind of consensus that we're all comfortable with releasing the code
in the current state -- even for an alpha release -- and that's not
necessarily expressed as showstopper bugs. Maybe the reminder mail
could include an exhortation to create new showstopper issues for
anything that a developer feels should really be addressed before the
release, even if it's not thought of a bug. The release reminder
emails act as a kind of wake-up call to many developers.

Another little trick we're using in my group at Google is to have a
bug that tracks a specific release. I've found this is particularly
handy once releases are done from release branches, and fixes in the
dev branch need to be "cherry-picked". But if you just want to use the
mailing list for this that's probably fine too.

>  > 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).
>
>  I think neither of these use cases should get that far.  Neal and I
>  talked it over and we're in agreement that if a commit makes the
>  buildbots go red or breaks the build, we're going to just revert it.
>  Tough luck Joe Dev, please test your changes more carefully next time.

Sure.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)