642936 - Fennec flags needed for post 4.0 work.

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Administration, task)

Description

[Doug Turner (:dougt)]

Please add the following:

blocking-fennec-4.1 with +, -, BetaN+ and .x
wanted-fennec-4.1 +/-

Comment 1

[Marcia Knous [:marcia]]

Reed: Does adding a new custom field still have to be done on the backend?

Comment 2

[Doug Turner (:dougt)]

also please "disable" blocking-fennec: 2.0-.  We do not want any new bugs put into that bucket.

Comment 3

[Doug Turner (:dougt)]

just to be clear, don't remove it - we want queries to still work.  just disable the option so that people can't move bugs into that state.

Comment 4

[Marcia Knous [:marcia]]

did that part - it is now disabled.

(In reply to comment #3)
> just to be clear, don't remove it - we want queries to still work.  just
> disable the option so that people can't move bugs into that state.

Comment 5

[Stuart Parmenter]

Sorry for confusion -- please add 2.0- back.

Comment 6

[Marcia Knous [:marcia]]

re-enabled.

(In reply to comment #5)
> Sorry for confusion -- please add 2.0- back.

Comment 7

[:glob ✱]

doug, i'll work on getting these flags added for you.

currently this requires code modifications to bmo, so it's more than a simple configuration change i'm sorry.

i'll assume the same security that currently applies to blocking-fennec will extend to blocking-fennec-4.1 and wanted-feccec-4.1 (only fennec-drivers can set the flag).

i'll also assume the wanted-feccec-4.1 flag needs to be requestable too, making the list ?/+/-

Comment 8

[:glob ✱]

Attachment: patch for 3.6

Comment 9

[:glob ✱]

Attachment: patch for 4.0

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

We just talked about this on our triage call. We can probably get away with one blocking-fennec flag with ?, -, 4.0.1+, 5+ and 6+. There was debate about whether this should stay "blocking-fennec" or be renamed to "tracking-fennec"

In addition it seems like we'll need a status flag for each of these releases, so well need status-fennec4 with affected, unaffected, fixed and fixed 4.0.1 and status-fennec4 with affected, unaffected and fixed

Does this proposal make sense to everyone? Any objections or comments? Let's get this sorted out.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

I like the tracking-fennec flag idea. Do we need the status-fennecN flags if we can just use the status-firefoxN flags?

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to comment #11)
> I like the tracking-fennec flag idea. Do we need the status-fennecN flags if we
> can just use the status-firefoxN flags?

the only problem I can see with sharing the status flags is for point releases. Its not clear to me that fennec and firefox desktop will always have the same point releases.

CC'ing Christian for his opinion.

Comment 13

[Doug Turner (:dougt)]

what are the next steps here?

Comment 14

[:glob ✱]

blassey and mfinkle grabbed me on irc and clarified a few things

> We just talked about this on our triage call. We can probably get away with one
> blocking-fennec flag with ?, -, 4.0.1+, 5+ and 6+. There was debate about
> whether this should stay "blocking-fennec" or be renamed to "tracking-fennec"

these changes have been made to the existing blocking-fennec flag (along with adding 4.0.2+ and renaming 2.0- to -).

> In addition it seems like we'll need a status flag for each of these releases,
> so well need status-fennec4 with affected, unaffected, fixed and fixed 4.0.1
> and status-fennec4 with affected, unaffected and fixed

<blassey> the "we eventually need to figure this out" part is the status flags
<blassey> and that's a decision we need input from christian for
<blassey> basically whether desktop and mobile will share point releases or not

Comment 15

[David Lawrence [:dkl]]

Christian, can you comment on comment 12 and comment 14?

dkl

Comment 16

[:glob ✱]

closing this bug as it appears we don't need those flags.

if you "eventually figure out" what you need, please file a new bug with those requirements.