502769 - Create multi-state blocking/status flags for 1.9.1.x

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Samuel Sidler (old account; do not CC)]

Please create a multi-state flag to replace the blocking1.9.1.nn flags.

  flag name        value   sort key

  blocking1.9.1.   wanted  100
                   x+      200
                   ---     300 (default)
                   2+      999

Reed tells me we (not me, but admins anyway) can easily add new ones to this list so we'll later add 3+ with a value of 998 and so on.

This flag will start with 1.9.1.2, not 1.9.1.1.

Comment 1

[Samuel Sidler (old account; do not CC)]

Oh, I should mention, Reed also tells me a requirement for the blocking-fennec flag was the ability to search via quicksearch. That works fine with multi-state flags (like this new one), you just search as if it were a new field and not a flag.

Comment 2

[Reed Loden [:reed]]

What types of users / groups should be able to set each state?

Comment 3

[Reed Loden [:reed]]

What products does this apply to?

Comment 4

[Reed Loden [:reed]]

Products == Bugzilla products, that is.

Comment 5

[Samuel Sidler (old account; do not CC)]

Use the same product and group settings as the blocking1.9.1.1 flag.

Comment 6

[Reed Loden [:reed]]

(In reply to comment #5)
> Use the same product and group settings as the blocking1.9.1.1 flag.

I can grab the product settings from that, but the group settings is a bit different. There's no such thing as "requestable", etc., so every state is its own thing. What should users be able to set? You don't have '?' in your list, or else I would think '---' and '?'.

Comment 7

[Samuel Sidler (old account; do not CC)]

Err... whoops! I should've had ? in my list.

  blocking1.9.1.   wanted  100
                   x+      200
                   ---     300 (default)
                   ?       400
                   2+      999

Users should indeed see --- and ?.

Comment 8

[Samuel Sidler (old account; do not CC)]

And... I forgot the minus too, which should be right under the ? and have a value of 500.

Comment 9

[Samuel Sidler (old account; do not CC)]

Alright! New proposal... we're actually going to create two multistate flags to replace the wanted1.9.1.x and blocking1.9.1.2 (and later).

  blocking1.9.1  needed   100
                 ---      200 (default)
                 ?        300
                 -        400
                 .2+      998

  status1.9.1    ---          100
                 needstriage  200
                 unaffected   300
                 wontfix      400
                 wanted       500
                 .2-fixed     998

Comment 10

[Daniel Veditz [:dveditz]]

And replace the "fixed1.9.1.<x>" keywords

Comment 11

[Daniel Veditz [:dveditz]]

replacing the keywords isn't a request for reed to do, just expanding on why we now want two separate flags.

Comment 12

[Reed Loden [:reed]]

ok, I'll try to get this done first thing next week... ping me on Tuesday if I haven't said anything in here.

Comment 13

[Reed Loden [:reed]]

ok, part I is done. You can start using it. I'll work on part II later tonight, I hope. (don't ask what the parts mean... I know what they mean).

Comment 14

[Samuel Sidler (old account; do not CC)]

(In reply to comment #5)
> Use the same product and group settings as the blocking1.9.1.1 flag.

This didn't happen because I can't edit the new blocking1.9.1 flag at all. "You tried to change the blocking1.9.1 field from ---  to .2+  , but only a user with the required permissions may change that field."

Did you do this right?

Comment 15

[Samuel Sidler (old account; do not CC)]

Oh, and can you make "needstriage" in the status1.9.1 flag editable by anyone?

Comment 16

[Samuel Sidler (old account; do not CC)]

Actually, now that I think about it, for status1.9.1, make all options settable by canconfirm, except "wanted" which should only be settable by mozilla-stable-branch-drivers.

Comment 17

[Dave Miller [:justdave]]

OK, per ss on IRC:

blocking1.9.1:
  --- and ? settable by canconfirm
  anything else settable by mozilla-stable-branch-drivers
status1.9.1:
  wanted settable by mozilla-stable-branch-drivers
  anything else (including --- and ?) settable by canconfirm.

Comment 18

[Dave Miller [:justdave]]

Committing to: /var/www/html/bmo/3.2/
modified Bugzilla/Bug.pm
Committed revision 6189.

Comment 19

[Dave Miller [:justdave]]

And now we have merge conflicts because reed apparently already tried to fix this in production and never bothered to commit it.  Likely scenario for why his fix didn't actually work is it requires an apache restart that probably didn't happen.  Attempting to clean up now...

Comment 20

[Dave Miller [:justdave]]

What reed already had in production:

Committing to: /var/www/html/bmo/3.2/
modified Bugzilla/Bug.pm
modified Bugzilla/Search/Quicksearch.pm
modified template/en/default/bug/edit.html.tmpl
modified template/en/default/bug/field.html.tmpl
Committed revision 6193.

I individually pulled the webheads out of rotation and restarted apache on them after traffic died off, then put them back in.  So what he had there should actually be running now.

Comment 21

[Mike Beltzner [:beltzner, not reading bugmail]]

Not seeing it live, but maybe it's not yet actually applied to bugs?

Comment 22

[Reed Loden [:reed]]

(In reply to comment #17)
> blocking1.9.1:
>   --- and ? settable by canconfirm
>   anything else settable by mozilla-stable-branch-drivers

I highly disagree. I believe anybody should be able to request blocking. We've had outside contributors come in and request blocking before for critical bugs, and by requiring canconfirm, we prevent them from doing that.

Comment 23

[Reed Loden [:reed]]

Ok, all done, except as noted in comment #22.

Comment 24

[Mike Shaver (:shaver emeritus)]

No, you should do as was requested.  Just because you're the person who can edit the files doesn't mean that you get veto over the requested configuration.  Please configure the flag as requested by Sam, immediately, and feel free to have a conversation about what a better configuration might be afterwards.

(I think I agree that we shouldn't restrict to canconfirm, but it's unlikely that people without canconfirm will know how to use that flag correctly, so they should just comment in the bug and have someone else twiddle it for the right branches, etc.)

Comment 25

[:Gavin Sharp [email: [e-mail]]]

I don't think there's a strong need to change this behavior now, so I think defaulting to the equivalent of the previous behavior is fine for now, and we can followup when we're less time constrained.

Comment 26

[Samuel Sidler (old account; do not CC)]

Yes, the previous behavior is fine. I was tired. Nomination for blocking1.9.1 shouldn't be restricted to canconfirm.