648555 - Multistate flags for tracking Firefox 5 and Firefox 6

Status: RESOLVED FIXED

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

Description

[Benjamin Smedberg]

Per newsgroup discussion, we would like to have the following flags for tracking Firefox 5 and 6. This needs to happen by Tuesday, although earlier would be better.

tracking-firefox5:
  "?" - set by anyone with editbugs
  "+" - set by release drivers (the people who can currently set blocking2.0)
  "-" - set by release drivers

status-firefox5: all values settable by anyone with editbugs
  "unaffected"
  "affected"
  "fixed"

Then we'll also need tracking-firefox6, with the same values as tracking-firefox5. We do not need status-firefox6 yet. But we will need a new set of flags every six weeks.

I'm not sure who can do this: it's something that legneato or smooney should probably be able to do.

Comment 1

[:glob ✱]

Attachment: patch for bmo 3.6

patch for bmo 3.6.

note these changes only need to be made once, future tracking flags won't require code changes unless the governance rules are changed.

Comment 2

[Gervase Markham [:gerv]]

Unless I've got two ideas confused, there seems to still be discussion about this in the newsgroup... Sheila Mooney has proposed an alternative. And I think we should be reclaiming "Version" and "Target Milestone". 

Do we need to wait for this to shake out?

Gerv

Comment 3

[David Lawrence [:dkl]]

Comment on attachment 524656 [details] [diff] [review]
patch for bmo 3.6

Looks proper to me as long as you have tested it :) r=dkl

Comment 4

[Benjamin Smedberg]

This is the alternative which Sheila posted, and which we have decided to do since there were no objections in the newsgroup and we need these for Tuesday.

The version and TM fields cannot solve the set of use cases we need to track.

Comment 5

[:glob ✱]

justdave, i've committed the changes to 3.6 and shifted the staging tag.  can you please create the 3 custom fields on staging and update.

Comment 6

[:glob ✱]

Attachment: patch for bmo 4.0

bmo 4.0 patch; i'll wait for sanity checks to complete on 3.6 before requesting a review.

Comment 7

[Sheila Mooney]

When do we think this will be completed? Any chance it can be wrapped up today? Our plan is to move to Aurora tomorrow so we will want these flags in place when we start logging bugs.

Comment 8

[JP Rosevear [:jpr]]

Talked to justdave, he will try and have this up for the first aurora meeting on Tuesday.

Comment 9

[Dave Miller [:justdave]]

This is live on bugzilla-stage, assuming we don't find any problems there it'll get pushed to production shortly.

Comment 10

[JP Rosevear [:jpr]]

Any issues found on stage or can we push this into production?

Comment 11

[David Lawrence [:dkl]]

(In reply to comment #10)
> Any issues found on stage or can we push this into production?

I think justdave is working through some issues now with moving this out to production. It is not easy these days to add custom fields due to the size of the BMO database.

dkl

Comment 12

[Dave Miller [:justdave]]

The code went live on bugzilla production last night.  So far I've only been able to successfully add tracking-firefox5.  Every attempt I've made to add status-firefox5 so far has gotten killed before it completed due to lock contention.

It'll either need to be done later at night when there's fewer people using Bugzilla or we'll need to take an outage window for it and actually prevent people from accessing bugzilla while it's being added (it takes about 3 to 5 minutes, and nobody can modify any bugs while it runs)

Comment 13

[David Lawrence [:dkl]]

Comment on attachment 524727 [details] [diff] [review]
patch for bmo 4.0

Looks good. r=dkl

Comment 14

[JP Rosevear [:jpr]]

(In reply to comment #12)
> The code went live on bugzilla production last night.  So far I've only been
> able to successfully add tracking-firefox5.  Every attempt I've made to add
> status-firefox5 so far has gotten killed before it completed due to lock
> contention.
> 
> It'll either need to be done later at night when there's fewer people using
> Bugzilla or we'll need to take an outage window for it and actually prevent
> people from accessing bugzilla while it's being added (it takes about 3 to 5
> minutes, and nobody can modify any bugs while it runs)

Triage meetings began today and will continue on Thursday so we need to move this ahead one way or another, in the next 24 hours if possible.  I leave it to the judgement of IT which approach is better.

Comment 15

[Dave Miller [:justdave]]

I've tried multiple times over the last day or so (and in the middle of the night) to add the other two fields, and had it die on me every time because someone would try to update a bug while it was running, which starts a 50 second countdown to breaking the lock the alter table command is holding on the bugs table.

I think I'm going to have to go ahead and shut the site down for a few minutes to run this update later tonight.

Comment 16

[JP Rosevear [:jpr]]

Thanks for following up Dave.

Comment 17

[Dave Miller [:justdave]]

We wrote a short apache rewrite and a cgi with a downtime message and set it up to ONLY block POST requests to attachment.cgi, process_bug.cgi, and post_bug.cgi, and let everything else still work, and dropped that in place for the duration of adding the fields.  Worked like a charm (and hopefully wasn't too disruptive to anyone).  All three fields are now created.  Byron's working on the setting up the values in them still, but the hard part was getting them created to begin with, and that's done now.

Comment 18

[:glob ✱]

the flags have been set up and should now be active.

4.0 branch updated..
Committing to: bzr+ssh://[e-mail]/bmo/4.0/
modified extensions/BMO/lib/Data.pm
Committed revision 7593.

Comment 19

[David Lawrence [:dkl]]

Reopening as the new flags fields are requestable '?' by users outside of the 'editbugs' group. 

# Who can request "cf_blocking_*"?
our $blocking_trusted_requesters = {
    qr/^cf_blocking_thunderbird/  => 'thunderbird-trusted-requesters',
    '_default'                    => 'everyone',
};

Should be

our $blocking_trusted_requesters = {
    qr/^cf_blocking_thunderbird/  => 'thunderbird-trusted-requesters',
    qr/^cf_tracking_firefox/      => 'editbugs',
    '_default'                    => 'everyone',
}

dkl

Comment 20

[Reed Loden [:reed]]

Please hold off on making that change. I'm not sure how that made it past generic review, but we've discussed this for years and decided against locking down nominations on a consistent basis, so I'm not sure why we'd want to change that now. I'll bring this up on dev-planning.

Comment 21

[Benjamin Smedberg]

Reed, were you going to start that discussion on .planning, or should I?

Comment 22

[:glob ✱]

(In reply to comment #20)
> Please hold off on making that change. I'm not sure how that made it past
> generic review, but we've discussed this for years and decided against
> locking down nominations on a consistent basis, so I'm not sure why we'd
> want to change that now. I'll bring this up on dev-planning.

a similar request for limiting status nominations to editbugs has appeared for thunderbird in bug 662494.

what's happening with this decision/discussion?

Comment 23

[David Lawrence [:dkl]]

Reed, does this discussion per comment 22 still need to happen and if so do you care to start that?

dkl

Comment 24

[Reed Loden [:reed]]

(In reply to David Lawrence [:dkl] from comment #23)
> Reed, does this discussion per comment 22 still need to happen and if so do
> you care to start that?

Benjamin, do you still think this is needed, a year and a half later?

Comment 25

[Benjamin Smedberg]

After an initial education period the current flag setup appears to be working.