Re: Using Bugzilla for freeze break requests?

[Andre Klapper <ak-47 gmx net>]

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.
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).

Flags are displayed in Bugzilla as a dropdown menu.
The following statuses can be possible:
*     (flag never requested)
*  ?  (requested)
*  -  (rejected)
*  +  (approved)

Flags can be queried for, however it's better if an email is
automatically sent to affected parties whenever a request flag has been
set (Olav said he'd investigate once some more Bugzilla maintenance work
has been done, hence targetting GNOME 3.5 instead of 3.3). 
Doing this via pseudo accounts (like "string-freeze-break gnome bugs")
would allow non-affected but interested parties (like distributions) to
also receive notifications via their Bugzilla users watchlist.


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
| 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.

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").


andre
-- 
mailto:ak-47 gmx net | failed
http://blogs.gnome.org/aklapper