Re: Using Bugzilla for freeze break requests?
- From: Bastien Nocera <hadess hadess net>
- To: Olav Vitters <olav vitters nl>
- Cc: Translation Team <gnome-i18n gnome org>, gnome-doc-list <gnome-doc-list gnome org>, Desktop Hackers <desktop-devel-list gnome org>, release-team <release-team gnome org>
- Subject: Re: Using Bugzilla for freeze break requests?
- Date: Fri, 23 Sep 2011 12:51:04 +0100
On Fri, 2011-09-23 at 09:40 +0200, Olav Vitters wrote:
> On Thu, Sep 22, 2011 at 10:44:32PM +0100, Bastien Nocera wrote:
> > I think that, at the very least for GNOME 3.4 onwards, we should switch
> > to using a keyword in bugzilla, and the release-team, docs team and i18n
> > teams can monitor newly request breaks, through RSS feeds (the design
> > team does that), and get the keywords cleared when the freeze break has
> > a result.
> The Bugzilla way of doing this is to use flags. A flag is either defined
> for attachments _or_ (not and) bugs. This is possible on our currently
> bugzilla; we just do not use them.
I specifically didn't want to use flags because I know that they're too
heavy duty for our uses, and I've had more than enough experience of
them through the Red Hat Bugzilla.
Here's the workflow with a keyword:
1. Developer adds a patch to an important bug, and realises that the
patch needs to make it to stable during a freeze (possibly through a
banner, auto-updated via ical)
2. Developer adds "freeze-break" keyword
3. Bug shows up on release-team, docs-team, etc.'s RSS feeds, or
hand-made search requests
4. First person from affected teams goes to check it out. If the patch
isn't relevant, drop keyword, disappears from 3., if not, adds mention
6. r-t member removes keyword
Use human brains to make sense of it. The only thing the developer needs
to know is the keyword to add. The release team knows the rest.
] [Thread Prev