On Tue, Mar 18, 2008 at 8:39 AM, Barry Warsaw <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
