Re: Using Bugzilla for freeze break requests?
- From: Bastien Nocera <hadess hadess net>
- To: Andre Klapper <ak-47 gmx net>
- Cc: Translation Team <gnome-i18n gnome org>, gnome-doc-list <gnome-doc-list gnome org>, desktop-devel-list gnome org, release-team <release-team gnome org>
- Subject: Re: Using Bugzilla for freeze break requests?
- Date: Tue, 07 Feb 2012 14:40:39 +0000
On Tue, 2012-02-07 at 13:15 +0100, Andre Klapper wrote:
> On Thu, 2011-09-22 at 22:44 +0100, Bastien Nocera wrote:
> > After having to send in another code freeze break request e-mail, I
> > realised that the process is problematic. Apart from the release team
> > and the patch sender, nobody else knows about the freeze break request,
> > or about the status of the request.
>
>
> After having talked to Olav Vitters at FOSDEM I (or we?) would like to
> propose using Bugzilla flags for freeze break requests in GNOME 3.5.
Awesome!
> Personally I consider keywords too cumbersome plus too easy to forget.
>
> Please also read Olav's initial comments on this thread again:
> https://mail.gnome.org/archives/desktop-devel-list/2011-September/msg00147.html
>
> This proposal applies to those Bugzilla products which already have a
> "GNOME Target" field (based on their Bugzilla classification / GNOME
> moduleset).
>
<snip explanation of flags>
>
> https://live.gnome.org/ThreePointThree#Schedule lists:
>
> | Development Stage | To decide | To notify
> +------------------------+---------------+----------------------
> | UI Freeze | 2x rel-team | gnome-doc
> | API/ABI Freeze | 2x rel-team | ---
> | String Change Announce | --- | gnome-i18n, gnome-doc
The "String change announce" period should be a simple CC: rather than a
new flag.
> | String Freeze | 2x gnome-i18n | rel-team, gnome-doc
> | Hard Code Freeze | 2x rel-team | ---
>
> Initially I favored having three flags (r-t, doc, i18n) but that leaves
> us with the problem how to implement the notifications.
> Hence I propose five flags.
Is it possible to add CC: for patch flags? Because it's really the
patches that should have the flags, not the bug itself.
> IIRC flags can either refer to reports or attachments. For code changes
> a patch to review is needed, however trivial changes could easily be
> committed without having the hassle to attach a patch first. Undecided.
>
> In case a comment can automatically be added to the bug report when a
> request flag is set (Olav should know), the comment could include
> reasons for receiving that bugmail (team X to decide; team Y only
> notified) and expectations (2 members of team X to add "Yes/No" comments
> to the bug report, 2nd member with "Yes" comment must set requested flag
> to "approved").
Overall, I don't really care about how it's implemented in Bugzilla
itself, as long as the UI isn't overly cumbersome, and we can hide those
UI elements when outside the freezes.
Glad to see movement on it!
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]