520863 - Add status1.9.2 multi-state flag to Websites::getpersonas.com

Status: VERIFIED FIXED

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

Description

[Johnathan Nightingale [:johnath]]

When a bug came up on getpersonas.com that we wanted to mark as blocking firefox3.6, beltzner added the appropriate blocking flag to the component (see bug 518806). However, now that it's been fixed, we have no status1.9.2 flag to set, in order to mark the now-fixed bug as fixed.  beltzner and mconnor are fearful of adding that flag, since it's a tricksy multi-state concoction, not a simple flag.

Who dares tempt the fates in this way?

Comment 1

[Mike Connor [:mconnor]]

It's not so much fear, more "I don't think I can control that from the UI, and if I can, it's UI I can't find" :)

Comment 2

[Reed Loden [:reed]]

There is no way to do this from the UI, as the multi-state "flags" are just a hack. Any changes like this require an actual code change to bmo's code. Is this absolutely needed?

Comment 3

[Johnathan Nightingale [:johnath]]

Having a way to track when blockers are resolved is something we should support, yes.

I hear what you're saying about not wanting to alter code for a one-off situation, and really, for this one we can just keep it in our heads or filter it out, or something. But when we added this multi-state "flag" it was because it was better than the other options - it was a feature that helped us work better, and was more flexible than the "fixed1.9.1" keyword approach that we used before. The keyword approach did *not* have a limitation, though, where trying to apply it to new components provoked exasperated sighs or, worse, code and stability risk - it seems that we have regressed, there? This individual component change is not absolutely needed, no, but I think in general the flexibility to be able to do this is.

Comment 4

[Reed Loden [:reed]]

(In reply to comment #3)
> Having a way to track when blockers are resolved is something we should
> support, yes.

Sure. Please don't take my comment to mean that we shouldn't ever support this. It's just a huge pain currently to modify actual Bugzilla code, so making sure it's absolutely needed goes a long way towards productivity of the person making the change.

> I hear what you're saying about not wanting to alter code for a one-off
> situation, and really, for this one we can just keep it in our heads or filter
> it out, or something. But when we added this multi-state "flag" it was because
> it was better than the other options - it was a feature that helped us work
> better, and was more flexible than the "fixed1.9.1" keyword approach that we
> used before. The keyword approach did *not* have a limitation, though, where
> trying to apply it to new components provoked exasperated sighs or, worse, code
> and stability risk - it seems that we have regressed, there? This individual
> component change is not absolutely needed, no, but I think in general the
> flexibility to be able to do this is.

I never once said that this was the be-all-end-all solution to our branch tracking problems. When I wrote this hack in early February based on what stuart and beltzner wanted, I made very sure to point out to both of them that this is indeed nothing more than a large hack that used existing Bugzilla functionality in a different way to "fake" what was needed. It's most definitely not as flexible in the sense of keywords, but it also enables a different type of tracking than what was possible in the past.

I do indeed wish that this functionality was better modular and could be controlled via the admin UI like its predecessors, but that's just not possible currently without some major code changes. If somebody were to take the time and effort to modify Bugzilla to better support things like this, I think the best and quickest way to success would to modify the existing flags code to support multiple fields besides ?/+/-.

However, until somebody spends the time or pays somebody to modify Bugzilla in that or a similar way to increase modularity and flexibility of this "feature", the existing (limited) functionality will have to continue to be used. Maybe you can work with various MoCo people to get this done so that future use of these "flags" is a much happier thing for all.

Comment 5

[Dave Miller [:justdave]]

status-1.9.2 exists, it's just a matter of allowing it to be used on that component.  That's easy.

modified template/en/default/bug/edit.html.tmpl
modified template/en/default/bug/show.xml.tmpl
modified template/en/default/bug/create/create.html.tmpl
Committed revision 6727.

Should be live in a few minutes.

Comment 6

[Johnathan Nightingale [:johnath]]

Thanks, Dave! Marked that bug final-fixed.