560523 - create blocking-seamonkey2.1 and status-seamonkey2.1 fields

Status: VERIFIED FIXED

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

Description

[Robert Kaiser]

We've been working on SeaMonkey 2.1 based on Mozilla 1.9.3 for some time now, and are starting concrete planning for milestones, so some new flags would be nice.

We'd like to switch over to the new-style custom fields as well there, so we should get those created now.

Those values should be supported (for now):

blocking-seamonkey2.1:
 ---
 ?
 -
 needed
 a1+
 a2+
 b1+
 final+

status-seamonkey2.1:
 ---
 ?
 wanted

I guess there's no tooling for an automated move of the current flags to those fields, but we should disable the blocking-seamonkey2.1a1 and wanted-seamonkey2.1 flags right away, so people can't request them an more, that should all be done via the new fields, and we'll manually migrate over the states in triage.

Comment 1

[Robert Kaiser]

Oh, I forgot in this initial comment that, as for current flags, seamonkey-council should be able to set all states, anyone should be able to request ? on those fields.

Comment 2

[Marcia Knous [:marcia]]

Assigning to Reed since this is requesting creation of new flags.

Comment 3

[Reed Loden [:reed]]

Attachment: patch - v1

Comment 4

[Robert Kaiser]

Comment on attachment 440987 [details] [diff] [review]
patch - v1

Phew, I hope that will become less ugly with a future version of Bugzilla, this looks overly complicated. :(

>+    [% ELSIF field.name.match("^cf_blocking_seamonkey") OR field.name.match("^cf_status_seamonkey") %]
>+       [% NEXT UNLESS bug.product == "Composer" OR bug.product == "MailNews Core" OR
>+                      bug.product == "Mozilla Localizations" OR bug.product == "Other Applications" OR
>+                      bug.product == "SeaMonkey" %]

Not completely sure about "Composer", as that product was for the standalone composer, which never came rolling on Mozilla-hosted infrastructure.
And I wonder how much pain "Mozilla Localizations" will give us in the long term for all those flags (interesting that we have SeaMonkey's there but not Thunderbird's, BTW) given the upcoming split of that into a zillion of products. Still, nothing to worry for this specific change.

So, looks good to me, though I'm a bit unsure about Composer, but no harm if we don't use it there anyhow.

Comment 5

[Dave Miller [:justdave]]

modified Bugzilla/Bug.pm
modified Bugzilla/Search/Quicksearch.pm
modified template/en/default/bug/edit.html.tmpl
modified template/en/default/bug/show-multiple.html.tmpl
modified template/en/default/bug/show.xml.tmpl
modified template/en/default/bug/create/create.html.tmpl
Committed revision 6777.

and deployed to production.

This only adds the back-end code for dealing with the field if it shows up on a bug.  The fields still need to actually be created in the admin GUI, and I'd like to hold off on that briefly while I investigate a couple things.  I'm really not fond of subjecting the general public to an SQL error on every page load during the 3 minutes it takes to add each field.

Comment 6

[Dave Miller [:justdave]]

Reed: I figured out how to avoid the crash:  When you create the fields, make sure the "Is obsolete" box is checkmarked.  The code that's crashing while the data setup is still incomplete is explicitly looking for active fields, so as long as the field is initially created as obsolete I believe it won't crash show_bug.  Once it's created you can go back and edit the field and uncheck the box.

Comment 7

[Dave Miller [:justdave]]

ok, hold off while I continue to test if it's not already too late, I tried to test that theory on the staging site and it didn't work (it still crashed).

Comment 8

[Dave Miller [:justdave]]

OK, you're cleared.  The manual workaround works.  My patch to try to make it automatic just doesn't.  I'll keep working on the patch, in the meantime, manually setting it to obsolete on creation successfully avoids a crash.

Comment 9

[Dave Miller [:justdave]]

And you no longer need the workaround.  Got a working patch for bug 531243 and it's been deployed to production.

Comment 10

[Robert Kaiser]

Dave, thanks for this work!

What's the next step here? Who is doing it? What's the ETA?

Comment 11

[Reed Loden [:reed]]

Ok, all done. Let me know if you see anything incorrect or have any problems.

Comment 12

[Robert Kaiser]

Looks like seamonkey-council doesn't get mail for changes of those fields, but we do for the other flags. Is that normal for those custom fields?

Comment 13

[Reed Loden [:reed]]

(In reply to comment #12)
> Looks like seamonkey-council doesn't get mail for changes of those fields, but
> we do for the other flags. Is that normal for those custom fields?

Indeed, that is normal. If you want to file a bug requesting that feature be added, feel free, but I'm not sure when I'll have time to write it.

One creative thing you could do is use whines to get a similar effect.

Comment 14

[Robert Kaiser]

Thanks, good to know. I have http://dev.seamonkey.at/#radars display counts of and links to the relevant bug lists, but I appreciated getting council mail for those changes with the real flags to be fast to react.

Meanwhile, I also realized the custom fields don't show who actually requested a flag, which is also handy with the real flags, but I guess even harder to implement with those fields.

I'll file a bug at least on the "send mail on changes" things, even if just as a reminder of something that would be nice to have.

Comment 15

[Robert Kaiser]

Oh, forgot to note in the last comment, I now did triage all old flags we retired for this and it looks like those new flags nicely work as promised. Thanks a lot!

Comment 16

[Robert Kaiser]

As a note, bug 562102 filed on the "send mail on changes" for custom fields.