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
Re: clutter "default:LTR"
On Fri, 2011-09-23 at 07:43 +0100, Emmanuele Bassi wrote: > > On 23 September 2011 02:29, Colin Walters wrote: > > Many translations in clutter for "default:LTR" are broken; this causes a > > warning at startup. > > > > to the translators: this works exactly like the identical string in gtk+: > > http://git.gnome.org/browse/gtk+/tree/gtk/gtkmain.c#n843 And while we're at it, it's the same string used in yelp-xsl. dz: སྔོན་སྒྲིག་:ཨེལ་ཊི་ཨར། et: LTR mk: стандардно:LTR mn: Стандарт:LTR ne: पूर्वनिर्धारित:LTR sl: privzeto:LTR -- Shaun ___ 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?
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 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 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: pybliographer 1.2.15 will be released soon
On Thu, 2011-09-22 at 22:02 +0200, Zoltan Kota wrote: > I plan to push a new release of pybliographer next week. Please, check > your translations! I've checked your strings instead, and filed https://sourceforge.net/tracker/?func=detail&aid=3413277&group_id=4825&atid=104825 about missing plural handling. ;-) andre -- mailto:ak...@gmx.net | failed http://blogs.gnome.org/aklapper | http://www.openismus.com ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
Re: pybliographer 1.2.15 will be released soon
Am 22.09.2011 22:02, schrieb Zoltan Kota: > Hi, > > I plan to push a new release of pybliographer next week. Please, check > your translations! > Thanks! > > Zoltan > ___ > gnome-i18n mailing list > gnome-i18n@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-i18n > > There's still a problem with displaying the help. I've just installed the current Git content to /usr/local. When I try to open the manual from the menu bar, I get the following error: "Can't display documentation: Unable to find help paths /usr/local/share/gnome/help/pybliographer or /usr/share/gnome/help/pybliographer. Please check your installation" The appropriate files have been installed in /usr/local/share/gnome/help/pybliographer/C/ anyway. If I run "yelp ." in this folder, no problem, Yelp shows the help as expected. This issue should be solved before a new Pybliographer version will be published. Best Regards, Mario ___ 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 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, Sep 23, 2011 at 09:57:15AM +0100, Ross Burton wrote: > On 23 September 2011 08:40, Olav Vitters 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 08:40, Olav Vitters 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?
Op Vr, 2011-09-23 om 10:11 +0200 skryf Jorge González: > On Fri, Sep 23, 2011 at 09:53, Baptiste Mille-Mathias > wrote: > > On Fri, Sep 23, 2011 at 9:40 AM, Olav Vitters 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 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?
On Fri, Sep 23, 2011 at 09:53, Baptiste Mille-Mathias wrote: > On Fri, Sep 23, 2011 at 9:40 AM, 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. >> >> 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 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 9:40 AM, 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. > > 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: clutter "default:LTR"
Den 23-09-2011 09:30, Kenneth Nielsen skrev: Den 23-09-2011 03:29, Colin Walters skrev: Many translations in clutter for "default:LTR" are broken; this causes a warning at startup. http://git.gnome.org/browse/clutter/tree/clutter/clutter-main.c#n485 Here's what seems to be affected: po/da.po:msgid "default:LTR" po/da.po-msgstr "" po/kn.po:msgid "default:LTR" po/kn.po-msgstr "" po/or.po:msgid "default:LTR" po/or.po-msgstr "ପୂର୍ବ ନିର୍ଦ୍ଧାରିତ:LTR" po/pa.po:msgid "default:LTR" po/pa.po-msgstr "" po/pt_BR.po:msgid "default:LTR" po/pt_BR.po-msgstr "Padro: LTR" po/ta.po:msgid "default:LTR" po/ta.po-msgstr "முன்னிருப்பு :LTR" po/te.po:msgid "default:LTR" po/te.po-msgstr "" po/uk.po:msgid "default:LTR" po/uk.po-msgstr "типово:LTR" po/zh_HK.po:msgid "default:LTR" po/zh_HK.po-msgstr "預設：LTR" po/zh_TW.po:msgid "default:LTR" po/zh_TW.po-msgstr "預設：LTR" For da a translation is being worked on. That being said, IMO this is broken. Programs should NEVER rely on programmatic input from translations. If there is no translation OR if it fails a parse test (which there absolutely should be) it should default to a built-in value. Ah wait. I read the original email wrong. It just said that it produced "a warning", which of course means that it is being handle. Disregard med previous email. (Note to self, read email before replying) Sorry, Kenneth Regards Kenneth ___ 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: clutter "default:LTR"
Den 23-09-2011 03:29, Colin Walters skrev: Many translations in clutter for "default:LTR" are broken; this causes a warning at startup. http://git.gnome.org/browse/clutter/tree/clutter/clutter-main.c#n485 Here's what seems to be affected: po/da.po:msgid "default:LTR" po/da.po-msgstr "" po/kn.po:msgid "default:LTR" po/kn.po-msgstr "" po/or.po:msgid "default:LTR" po/or.po-msgstr "ପୂର୍ବ ନିର୍ଦ୍ଧାରିତ:LTR" po/pa.po:msgid "default:LTR" po/pa.po-msgstr "" po/pt_BR.po:msgid "default:LTR" po/pt_BR.po-msgstr "Padro: LTR" po/ta.po:msgid "default:LTR" po/ta.po-msgstr "முன்னிருப்பு :LTR" po/te.po:msgid "default:LTR" po/te.po-msgstr "" po/uk.po:msgid "default:LTR" po/uk.po-msgstr "типово:LTR" po/zh_HK.po:msgid "default:LTR" po/zh_HK.po-msgstr "預設：LTR" po/zh_TW.po:msgid "default:LTR" po/zh_TW.po-msgstr "預設：LTR" For da a translation is being worked on. That being said, IMO this is broken. Programs should NEVER rely on programmatic input from translations. If there is no translation OR if it fails a parse test (which there absolutely should be) it should default to a built-in value. Regards Kenneth ___ gnome-i18n mailing list gnome-i18n@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-i18n
