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-br...@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...@gmx.net | failed http://blogs.gnome.org/aklapper _______________________________________________ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
