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
1/2!
5. 2/2!
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.
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]