Re: Using Bugzilla for freeze break requests?
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
Re: Using Bugzilla for freeze break requests?
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. For flags you could have e.g. code_freeze_break flag string_freeze_break flag ui_freeze_break flag or perhaps just freeze_break (bit easier IMO) Flags can have 3 things: ? request it to be set - request denied + request approved Then there are settings to control: * who can request * who can approve/deny * who should be cc'ed on the request (release-team, etc) Drawbacks: * IMO UI is complicated and Bugzilla is slower than just email * I think only the request gets CC'ed to release-team. None of the following comments will be (AFAIK.. could be wrong) that would be pretty annoying * it is either + or -.. nothing about needing two approvals. Can be solved by using comments though (1st person says +1 in a comment; second sets the '+' on the flag). Flags have a lot of options, so above is my idea about how it should be used. Some of the stuff is IMO just confusing. -- Regards, Olav ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Fri, Sep 23, 2011 at 9:40 AM, Olav Vitters o...@vitters.nl 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. For flags you could have e.g. code_freeze_break flag string_freeze_break flag ui_freeze_break flag or perhaps just freeze_break (bit easier IMO) Flags can have 3 things: ? request it to be set - request denied + request approved Then there are settings to control: * who can request * who can approve/deny * who should be cc'ed on the request (release-team, etc) Drawbacks: * IMO UI is complicated and Bugzilla is slower than just email * I think only the request gets CC'ed to release-team. None of the following comments will be (AFAIK.. could be wrong) that would be pretty annoying * it is either + or -.. nothing about needing two approvals. Can be solved by using comments though (1st person says +1 in a comment; second sets the '+' on the flag). Flags have a lot of options, so above is my idea about how it should be used. Some of the stuff is IMO just confusing. As Bastien reported it is also hard to know we're currently on string freeze period; would be possible to have some banner information displayed in bugzilla for official modules during freeze stating the current restriction ? Regards -- Baptiste Mille-Mathias Les gens heureux ne sont pas pressés [w] http://damnpeople.fr ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Fri, Sep 23, 2011 at 09:53, Baptiste Mille-Mathias baptiste.millemath...@gmail.com wrote: On Fri, Sep 23, 2011 at 9:40 AM, Olav Vitters o...@vitters.nl 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. For flags you could have e.g. code_freeze_break flag string_freeze_break flag ui_freeze_break flag or perhaps just freeze_break (bit easier IMO) Flags can have 3 things: ? request it to be set - request denied + request approved Then there are settings to control: * who can request * who can approve/deny * who should be cc'ed on the request (release-team, etc) Drawbacks: * IMO UI is complicated and Bugzilla is slower than just email * I think only the request gets CC'ed to release-team. None of the following comments will be (AFAIK.. could be wrong) that would be pretty annoying * it is either + or -.. nothing about needing two approvals. Can be solved by using comments though (1st person says +1 in a comment; second sets the '+' on the flag). Flags have a lot of options, so above is my idea about how it should be used. Some of the stuff is IMO just confusing. As Bastien reported it is also hard to know we're currently on string freeze period; would be possible to have some banner information displayed in bugzilla for official modules during freeze stating the current restriction ? There could be a shared calendar. I have my own to know when we release and when are we in string freeze and such. It's very easy. Regards Regards. -- Baptiste Mille-Mathias Les gens heureux ne sont pas pressés [w] http://damnpeople.fr ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n -- Jorge González González alor...@gmail.com Weblog: http://aloriel.no-ip.org Fotolog: http://www.flickr.com/photos/aloriel ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Fri, Sep 23, 2011 at 10:11:13AM +0200, Jorge González wrote: There could be a shared calendar. I have my own to know when we release and when are we in string freeze and such. It's very easy. http://www.gnome.org/start/unstable/schedule.ics webcal://www.gnome.org/start/unstable/schedule.ics it is mentioned on the wiki, as well as: http://www.gnome.org/start/unstable (which links to the current wiki page). It is generated by our schedule scripts (see releng/tools/schedule), then uploaded manually. We send out the freezes to devel-announce-list as well. Bugzilla would be manual. I like the idea, but fear we'd not keep it up to date. -- Regards, Olav ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
Op Vr, 2011-09-23 om 10:11 +0200 skryf Jorge González: On Fri, Sep 23, 2011 at 09:53, Baptiste Mille-Mathias baptiste.millemath...@gmail.com wrote: On Fri, Sep 23, 2011 at 9:40 AM, Olav Vitters o...@vitters.nl wrote: On Thu, Sep 22, 2011 at 10:44:32PM +0100, Bastien Nocera wrote: ... As Bastien reported it is also hard to know we're currently on string freeze period; would be possible to have some banner information displayed in bugzilla for official modules during freeze stating the current restriction ? I think any way to improve the visibility of the freezes will help. Also showing information about upcoming freezes can help to prepare people for them and maybe avoid some freeze breaks before they are necessary. There could be a shared calendar. I have my own to know when we release and when are we in string freeze and such. It's very easy. Indeed! webcal://www.gnome.org/start/unstable/schedule.ics I think André Klapper maintains this one. Friedel -- Recently on my blog: http://translate.org.za/blogs/friedel/en/content/virtaal-070-released ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On 23 September 2011 08:40, Olav Vitters o...@vitters.nl wrote: 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. For what it's worth this is exactly what we do in MeeGo for distribution freezes and we find it works very well. Ross ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Fri, Sep 23, 2011 at 09:57:15AM +0100, Ross Burton wrote: On 23 September 2011 08:40, Olav Vitters o...@vitters.nl wrote: 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. For what it's worth this is exactly what we do in MeeGo for distribution freezes and we find it works very well. Do you have multiple freezes? Do you use one flag or multiple? How do you handle multiple teams and e.g. one flag? My idea would be: * 1 flag, freeze_break * 3 teams having access to grant/deny (i18n+docs+r/t) with a limited amount of people we'd just rely on awareness instead of technical solutions. E.g. i18n team should not mark a break as 'approved' if we're in hard code freeze * only people marked as developers being able to request (simply to avoid confusing random users with a flag option) Could also have 3 flags: - UI - i18n+docs - feature - i18n+docs+r-t - string - i18n+docs - code - r-t then you'd just request the flags that are needed depending on the time. Big drawback that I think it would be confusing. Oh, and Bugzilla should just CC the flag CC list on the bug. Lastly, if you don't have access to Bugzilla, then sending an email reply should be enough as well (e.g. approved from docs, r-t please change flag). -- Regards, Olav ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On 23 September 2011 10:58, Olav Vitters o...@vitters.nl wrote: For what it's worth this is exactly what we do in MeeGo for distribution freezes and we find it works very well. Do you have multiple freezes? Do you use one flag or multiple? How do you handle multiple teams and e.g. one flag? We have a single freeze which does make things easier. There is a group of people who can approve the flag, they all have rights to it and we rely on clue so e.g. the netbook approver doesn't approve tablet requests. My idea would be: * 1 flag, freeze_break * 3 teams having access to grant/deny (i18n+docs+r/t) with a limited amount of people we'd just rely on awareness instead of technical solutions. E.g. i18n team should not mark a break as 'approved' if we're in hard code freeze * only people marked as developers being able to request (simply to avoid confusing random users with a flag option) Agreed that this alternative would be more sensible than presenting multiple flags. If you require that people explain what their change does so the approvers understand what freezes are being broken, then it should become automatically peer reviewed if say the i18n team approved a code change. Ross ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
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 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Fri, Sep 23, 2011 at 12:51:04PM +0100, Bastien Nocera wrote: 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. I think that will add too much burden on the people who have to approve? I don't track RSS at all. Release-team gets a lot of freeze breaks and I want to be notified immediately, not after a delay. I need to see the comments that other teams make immediately as well as they're generally quite useful. RSS doesn't do that. IMO for convenience for r-t, Bugzilla annoyance and developers, flags is best of all the options. If we limit flags ability to just being able to set a ? or nothing at all, I think it would be pretty similar to keywords right? I'll see if I can setup a flag thingy limited to you/limited set of people just to try it out. -- Regards, Olav ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On 09/23/2011 07:58 AM, Olav Vitters wrote: I think that will add too much burden on the people who have to approve? I don't track RSS at all. Release-team gets a lot of freeze breaks and I want to be notified immediately, not after a delay. I need to see the comments that other teams make immediately as well as they're generally quite useful. RSS doesn't do that. Instead of keywords, we could just add bugzilla pseudo accounts for string-freeze-br...@gnome.bugs, ui-freeze-br...@gnome.bugs, code-freeze-br...@gnome.bugs. Then to request a break, just cc: the appropriate address on the bug along with a comment explaining why. Release/docs/i18n team members would just watch the appropriate address and so automatically get cc:ed on all the appropriate bugs. -- Dan ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, 2011-09-22 at 21:24 -0400, Shaun McCance wrote: On Thu, 2011-09-22 at 22:44 +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. If I don't get email notifications, I can pretty much guarantee I won't deal with it promptly. I don't think you can subscribe to keywords in Bugzilla to get emails when bugs are tagged. I understand we'd get better tracking, but using Bugzilla is a lot more work than sending an email. I gave a docs ack for one UI freeze break request while on vacation from my phone. Using Bugzilla on a phone is unpleasant. Bugzilla is great for making sure stuff doesn't get lost. Do we have a real problem of requests getting lost? Sorry, slight thread hijack, but related. What we do actually have a problem with is not getting notifications for things. I just wasted an hour because I was still testing against 3.1.91 and didn't get a notification for this: https://bugzilla.gnome.org/show_bug.cgi?id=649452 That affects three pages in the help. It was made after the UI freeze, and well after the UI change announcement period. The reason we have these things is so that people can start writing about the unstable releases and not have to worry about being wrong. I don't mean to pick on you personally, Bastien. It's pretty obvious what a string change is, but I think a lot of developers don't have a clear sense of what a UI change is. So, if we use Bugzilla for this stuff: 1) How do pre-freeze notifications fit in? Add the keyword or flag but don't wait for approval? 2) How can we improve developer awareness of UI changes? The banner at the top of Bugzilla could help: We're in the UI change announcement period. Does this affect the UI or interaction in any way? If so, ... But I'd still really love to see emails going to gnome-doc-list. -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
Hi! Instead of keywords, we could just add bugzilla pseudo accounts for string-freeze-br...@gnome.bugs, ui-freeze-br...@gnome.bugs, code-freeze-br...@gnome.bugs. Then to request a break, just cc: the appropriate address on the bug along with a comment explaining why. Release/docs/i18n team members would just watch the appropriate address and so automatically get cc:ed on all the appropriate bugs. If we do that I would definitly suggest not to add individual people but the appropriate mailing list to those pseudo accounts. Especially for string freeze it is often really good to have more people looking at the added string because you will never know if any language might have difficulties with a phrase for one or the other reason. And it would keep things mostly the same from an approver POV as you would be notified and would get all feedback by bugmail. Regards, Johannes ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Using Bugzilla for freeze break requests?
Heya, 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. 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. That means that there's no problems with the timeline (patches that go in before the request got accepted for example), accountability and traceability, as well as visibility for the bugsquad and QA teams in downstream communities. Opinions? Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, 2011-09-22 at 22:44 +0100, Bastien Nocera wrote: Heya, 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. 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. That means that there's no problems with the timeline (patches that go in before the request got accepted for example), accountability and traceability, as well as visibility for the bugsquad and QA teams in downstream communities. Opinions? For example, nobody apart from the release-team here would know that I would have requested a freeze break for https://bugzilla.gnome.org/show_bug.cgi?id=659826 ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, Sep 22, 2011 at 5:44 PM, Bastien Nocera had...@hadess.net wrote: Heya, 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. 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. That means that there's no problems with the timeline (patches that go in before the request got accepted for example), accountability and traceability, as well as visibility for the bugsquad and QA teams in downstream communities. Opinions? I'm in favour of anything that makes the process more transparent and less annoying. Of course, one of the main purposes of freezes is to slow down the commit rate, so some annoyance will have to remain as a deterrent... ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, 2011-09-22 at 18:28 -0400, Matthias Clasen wrote: On Thu, Sep 22, 2011 at 5:44 PM, Bastien Nocera had...@hadess.net wrote: Heya, 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. 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. That means that there's no problems with the timeline (patches that go in before the request got accepted for example), accountability and traceability, as well as visibility for the bugsquad and QA teams in downstream communities. Opinions? I'm in favour of anything that makes the process more transparent and less annoying. Of course, one of the main purposes of freezes is to slow down the commit rate, so some annoyance will have to remain as a deterrent... I'm guessing that we'd need to refine the criteria for requesting freeze breaks, and that the release team would remove the keyword and put a reason why it didn't match the criteria in those cases. Cheers ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: Using Bugzilla for freeze break requests?
On Thu, 2011-09-22 at 22:44 +0100, Bastien Nocera wrote: Heya, 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. Who else needs to know about it? For UI and string freeze breaks, you have to notify the docs resp. i18n teams. The people who are interested in these sorts of things are subscribed to the mailing lists where they can find out about them. 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. If I don't get email notifications, I can pretty much guarantee I won't deal with it promptly. I don't think you can subscribe to keywords in Bugzilla to get emails when bugs are tagged. I understand we'd get better tracking, but using Bugzilla is a lot more work than sending an email. I gave a docs ack for one UI freeze break request while on vacation from my phone. Using Bugzilla on a phone is unpleasant. Bugzilla is great for making sure stuff doesn't get lost. Do we have a real problem of requests getting lost? -- Shaun ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
