Multi-state flags and branches
|
View:
New views
10 Messages
—
Rating Filter:
Alert me
|
 |
Multi-state flags and branches
by Mark Banner-2
::
Rate this Message:
A while ago, there were a series of multi-state flags set up for Gecko
releases: https://wiki.mozilla.org/Releases/Flags We're considering using similar multi-state flags for managing the Thunderbird releases. Before we do, a couple of quick questions: - How well have the multi-state flags gecko worked so far? - I guess some of the advantages are obvious, like not having to create lots of keywords that are only used a few times. However are there any other advantages or disadvantages over the old system of keywords and tri-state flags? Anything that would mean it wouldn't be worth adopting it for Thunderbird releases? Thanks in advance, Standard8 _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
|
|
Re: Multi-state flags and branches
by Robert Kaiser
::
Rate this Message:
Mark Banner wrote:
> However are there any other advantages or disadvantages over the old > system of keywords and tri-state flags? Anything that would mean it > wouldn't be worth adopting it for Thunderbird releases? One problem is that those new custom flags/fields are a pain in Bugzilla management from what I'm told, that's one major reason why I haven't really looked into going down that road for SeaMonkey yet, even though they seem better than adding yet another set of flags/keywords for every security update. Another problem is that you need to resort to boolean charts for every query that includes them and can't go with the rather convient keywords field for a search. Robert Kaiser _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
|
|
Re: Multi-state flags and branches
by Mike Beltzner
::
Rate this Message:
On 2009-10-23, at 7:42 AM, Mark Banner wrote:
> A while ago, there were a series of multi-state flags set up for > Gecko releases: https://wiki.mozilla.org/Releases/Flags > > We're considering using similar multi-state flags for managing the > Thunderbird releases. Before we do, a couple of quick questions: > > - How well have the multi-state flags gecko worked so far? I think they've worked quite well, though to date we've been using them primarily for the security and stability releases. Starting with Firefox 3.6 we've been using a mutli-state flag to indicate the milestone in which a bug was fixed on the mozilla-1.9.2 branch (using the same format as on the status1.9.1 flag) and starting with Firefox 3.7 we'll be using a multi-state flag for blocking status as well. > - I guess some of the advantages are obvious, like not having to > create lots of keywords that are only used a few times. Yes, as well as having greater specificity and clearer communication since the flags more clearly indicate when something was fixed or what specific milestone it blocks, without adding more and more flags. > However are there any other advantages or disadvantages over the old > system of keywords and tri-state flags? Anything that would mean it > wouldn't be worth adopting it for Thunderbird releases? They're not trivial to implement; every new one has required custom code to be provided by reed or justdave. Also, they're not located where people expect, all the way at the bottom right of the set of flags and fields. On 2009-10-23, at 9:01 AM, Robert Kaiser wrote: > Another problem is that you need to resort to boolean charts for > every query that includes them and can't go with the rather convient > keywords field for a search. The form doesn't have a specific place for them, no, but they do work well with the Bugzilla Quicksearch syntax, and are pretty readable in that format. For example: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20status1.9.2:fixed%20P1 cheers, mike _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
|
|
Re: Multi-state flags and branches
by Boris Zbarsky
::
Rate this Message:
On 10/23/09 7:42 AM, Mark Banner wrote:
> However are there any other advantages or disadvantages over the old > system of keywords and tri-state flags? The only thing I've run into as a developer, not driver, is that I can't set these flags from the new-bug page. A slight annoyance, but not fatal. -Boris _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
|
|
|
|
|
Re: Multi-state flags and branches
by Gervase Markham
::
Rate this Message:
On 23/10/09 16:32, Boris Zbarsky wrote:
> The only thing I've run into as a developer, not driver, is that I can't > set these flags from the new-bug page. A slight annoyance, but not fatal. https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox shows, for me, the ability to edit: blocking1.9.3 status1.9.2 blocking1.9.1 status1.9.1 between the URL and Summary fields. Have I misunderstood what you are asking? Gerv _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
|
|
Re: Multi-state flags and branches
by Boris Zbarsky
::
Rate this Message:
On 10/26/09 6:33 AM, Gervase Markham wrote:
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox > shows, for me, the ability to edit: > > blocking1.9.3 > status1.9.2 > blocking1.9.1 > status1.9.1 > > between the URL and Summary fields. Have I misunderstood what you are > asking? For me, it shows dropdowns for all 4, with the following options in each: blocking1.9.3: no options at all status1.9.2: unaffected, wontfix, beta1-fixed, final-fixed blocking1.9.1: no options at all status1.9.1: ?, unaffected, wontfix, .5-fixed, .4-fixed, .3-fixed, .2-fixed Which means I can't nominate a bug for blocking as I file it. Note that the case that does work for me (setting the status as I file) is pretty much useless for my purposes, which is why I hadn't even realized that those were settable: I'd never tried. -Boris _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
|
|
Re: Multi-state flags and branches
by Mike Beltzner
::
Rate this Message:
On 2009-10-26, at 9:08 AM, Boris Zbarsky wrote:
> blocking1.9.3: no options at all > blocking1.9.1: no options at all That's not right. You should have the permissions to set those to "?" > status1.9.2: unaffected, wontfix, beta1-fixed, final-fixed > status1.9.1: ?, unaffected, wontfix, .5-fixed, .4-fixed, .3-fixed, > .2-fixed As you say, these are showing the right permissions, but aren't all that useful at the point of filing (unless you know something is status1.9.1:unaffected) cheers, mike _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
|
|
|
|
|
Re: Multi-state flags and branches
by Daniel Veditz-2
::
Rate this Message:
On 10/26/09 7:51 AM, Boris Zbarsky wrote:
> On 10/26/09 10:37 AM, Mike Beltzner wrote: >> On 2009-10-26, at 9:08 AM, Boris Zbarsky wrote: >> >>> blocking1.9.3: no options at all >>> blocking1.9.1: no options at all >> >> That's not right. You should have the permissions to set those to "?" > > And I do, once the bug is filed. Just not on the enter_bug page. Which > means setting those flags is an extra step I have to take after filing > the bug. Not fatal; just mildly annoying. https://bugzilla.mozilla.org/show_bug.cgi?id=515214 Hopefully fixed after the upgrade to bugzilla 3.4 _______________________________________________ dev-planning mailing list dev-planning@... https://lists.mozilla.org/listinfo/dev-planning |
| Free embeddable forum powered by Nabble | Forum Help |
