Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Description • 14 years ago

It's nice that we're trying to be helpful by automatically filling in these values, but I think they're far more often wrong than right.

(As an alternative, we can have Bugzilla always include the UA string of the reporter in comment 0, which means that triagers will have that information to hand)

	Gervase Markham [:gerv]
	Comment 1 • 14 years ago

I believe Jesse has an alternative view here...

I think we could set it to All/All if we also did the UA thing you suggest.

Gerv

	LegNeato
	Comment 2 • 14 years ago

Perhaps a button next to it ("Set to my platform" or something) so it is easy to set if needed? I know the interface doesn't need more buttons...

	Jesse Ruderman
	Comment 3 • 14 years ago

I think we should remove the Arch/OS fields from BMO.  They're not part of the workflow most of the time, except to slow you down when you're filing a bug report.  Like most "required metadata" fields, they mean different things to different Bugzilla users, making them an unreliable source of data for everyone.  Any actual knowledge can be better expressed using part of the summary or a tag.

When I come across a Core bug marked as "Windows Vista", it can mean:
- Reported on Vista
- Reported on Vista, and happens *only* on Windows
- Happens *only* on Windows, and only on Vista
- Happens *only* on Windows, and only on Vista and *lower*
- Happens *only* on Windows, and only on Vista and *higher*

For Websites bugs, the field doesn't mean much of anything.

Sometimes I want to split a list of bugs based on the reporter's OS, so I can triage Mac-reported bugs on Mac and Windows-reported bugs on Windows.  It's not a very strong use case, but at least for me it's more common than wanting to be able to find bugs that definitely happen only on a specific OS or that definitely happen on all OSes.

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 4 • 14 years ago

I'd go for that as well - Jesse, I take it that you suggest that if bugs are OSX only the [OSX] convention be used in the summary?

	Jesse Ruderman
	Comment 5 • 14 years ago

Yes, if I know a bug is Mac-only, I add [Mac] to the summary.

	Gervase Markham [:gerv]
	Comment 6 • 14 years ago

Is any project (e.g. Mobile?) using Arch/OS in a consistent way? I don't want to propose removing them from the whole of b.m.o. without checking on how much they are currently used.

We could certainly replace them with keywords. Summary tags get ugly IMO. But whatever we do, we want an agreed single way of doing it so people can search for it.

Gerv

	Mike Beltzner [:beltzner, not reading bugmail] Reporter
	Comment 7 • 14 years ago

Gerv: works better if you cc those involved :)

dmose, KaiRo, Stuart, can you take a look and let us know if this would hurt you guys? I can't figure out how to cc: smokey, so someone else can do that part for me.

	Robert Kaiser
	Comment 8 • 14 years ago

I don't care. Categorization is Bugzilla is broken anyhow, if we destroy it more in one way or the other, it really doesn't matter, as the core problem is that people are unable to set the right fields, and as as we're trying to hide as many of the fields as possible, we are trading off ability to set them for easier reporting.
I'm using some logic based on those fields to make up a changes page for our relnotes, and they are wrong often enough that I'm not sure if people are just stupid or the fields mostly worthless.

	Gervase Markham [:gerv]
	Comment 9 • 14 years ago

I think this address CCs Smokey, but it has a nasty warning on it not to use it...

(Mike: do you not have user autocomplete? Not sure if I'm getting that from an add-on or whether it's now part of b.m.o. by default.)

KaiRo: I think bug filers are suffering from this problem:
http://www.joelonsoftware.com/news/20020912.html

Gerv

	Smokey Ardisson (offline for a while; not following bugs - do not email)
	Comment 10 • 14 years ago

(In reply to comment #9)
> I think this address CCs Smokey, but it has a nasty warning on it not to use
> it...

It adds this bug to my CC query, which means that I'll see it when I run the query ;)

In terms of Camino per se, it's pretty much irrelevant; "All/All" looks silly, of course, but we've only had one arch-specific bug in the past few years.

However, I've objected to this kind of change before, and I'll object to it again now from the "wider picture" view:

We have a bunch of products/components that that OS-specific code within a single Bugzilla item, and thus a bunch of OS-specific bugs.  I make heavy use of the fact that this field is more often right than wrong to make my queries only show me bugs from the platform I care about (i.e., Mac) when I work through these bugs.  (True, I haven't done a check to see how many Mac-only bugs are filed with Win7 as the OS, but the number of Win7 bugs I've seen filed with Mac OS X as the OS has been negligible, so I feel it's a safe assumption to make the other way.)

Getting rid of these fields, or setting them to "All/All" would severely impact my ability to keep tabs on Mac gfx and plug-in bugs, and, in turn, will pretty much stop me from doing any triage work there going forward.

1) If, supposedly, we can't rely on people to set these fields correctly, we certainly can't rely on them to add the appropriate summary tag; at least by using auto-detection, we have a shot at getting it right.  (Note that, in my experience, the fields being set incorrectly has been relatively rare--and almost exclusively by MoCo employees ;) ; is it more of a problem in front-end components/end-user products, or just in components I don't follow, like ones without much/any platform-specific code?)

2) When there's a real field, it's silly to overload something else if there's a continuing need for the value; worse, we're already crashing hard against summary length limitations in many places.

Since I don't think me objecting to the changes is going to convince everyone not to go through with them, let me propose a couple of alternatives that would make things less painful to me (and perhaps more useful broadly):

a) Set the default values in end-user-facing products to "All/All" (and let other products opt-in, as warranted, e.g. Webtools, Websites--and set Camino to All/Mac OS X ;) ), and possibly hide the OS/CPU fields on Bugzilla Helper.  We can have a reasonable expectation, I think, that anyone who is going to file a bug deep in Gecko is going to have enough of an idea of how Bugzilla works that they'll get it right, and we *should* have a reasonable expectation that QA/triage moving a bug out of an end-user-facing component into its proper Gecko component will set the value to a specific OS if warranted.

b) Set the default to "All/All" everywhere, but also record the "Reported in" value (e.g., UA), for everyone, and as a *separate field* (rather than as part of comment 0).  Possibly hide the OS/CPU fields on Bugzilla Helper.  This would allow the existing field to serve as "bug exists in", and be set to the right thing by triage or developers who know what they're reporting, but having "Reported in" be a discrete field means that anyone who wants to triage based on the reporter's OS can do so, e.g., I can still run my queries and find plug-in and graphics bugs that were reported against Mac OS X and are likely to be Mac-only.  (Making it a discrete field means you can query against that, rather than "a comment contains 'Mac'", which gets you lots of false positives, such as "I don't see this on Mac OS X".)

Both of these avoid overloading the summary with yet-another-tag for something that's reasonably common, and the latter option provides some added granularity that should help triage.  And, in theory, either should make it possible for me to still follow and help triage Mac-specific bugs in non-OS-specific Gecko components I care about.

	Dan Mosedale (:dmosedale, :dmose)
	Comment 11 • 14 years ago

My guess is that this would be a significant net win for Thunderbird, but CCing a few other Tb folks who are likely to have more informed opinions than I.

	Gervase Markham [:gerv]
	Comment 12 • 14 years ago

I agree that using summary tags is bad; keywords are designed for this use.

Reading the comments so far, here's an aggregated plan:

- Change all of b.m.o. to hide OS and Platform
- Change the bug filing form to record the UA in all cases, at the bottom of 
  the initial comment.
- Create keywords for "osx", "linux", "windows", and whatever other OSes or 
  platforms people actually do use those fields for.
- Define these keywords as meaning "this bug appears on this platform", without 
  limiting the other platforms it may or may not appear on.
- (Strongly discourage people from adding a bevy of keywords to buys which 
  appear on all OSes.)
- Migrate by adding the relevant keyword to all bugs where:
  - the OS or Platform has been changed since the initial bug was filed
  - the current value is not "All"
  - there exists a keyword for the current value

The keywords have the same function as the fields but without taking up extra space on bugs where they are not needed, and without misleading people. And the allowance of multiple values means we can be much clearer - e.g. when a bug appears only on OS X and Linux. I think that experts will adapt to the new keywords, and beginners are the people who get these fields wrong anyway.

Smokey: I think Mac UAs are distinct enough that a search for "bugs filed on Mac" wouldn't have too many false positives. Remember, you can search using a regexp, start the line with "Mozilla" and include the semicolon and the space after "OS X" too, which should be fairly unique to UAs.

Gerv

	Mark Banner (:standard8)
	Comment 13 • 14 years ago

(In reply to comment #12)
> - Change the bug filing form to record the UA in all cases, at the bottom of 
>   the initial comment.

That's a reasonable change, although for Thunderbird it'll still only give the UA of whatever the user is submitting the report from.

> - Change all of b.m.o. to hide OS and Platform
> - Create keywords for "osx", "linux", "windows", and whatever other OSes or 
>   platforms people actually do use those fields for.
> - Define these keywords as meaning "this bug appears on this platform", without 
>   limiting the other platforms it may or may not appear on.

I think using keywords is the wrong way to go. Keywords already tend to get abused by people who don't really understand what they are for (not helped by the mass of keywords especially obsolete ones that we already have), and I'm not convinced explaining what they are for will help.

The part I think is right is defining "this bug appears on this platform".

So my quick thoughts would be that you could replace the current hardware/OS fields by one listbox:

"Bug appears on: " and then have the platforms listed to match our tier 1 and probably tier 2 platforms (not sure if we'd want tier 3 as well, maybe incorporate those into an "Other" option).

If you want to go slightly more complex, then maybe you could have two options:

Bug is platform specific [x]
Bug appears on platforms [Windows]
                         [Mac]
                         [...]

So, if we believe the bug is platform specific, then you can tick the box, at which point you get to select which platforms the bug appears on.

The default for new bugs could be not-platform specific, but if platform-specific was ticked, then the platforms would be seeded with the platform of the original reporter.

	Robert Kaiser
	Comment 14 • 14 years ago

Of course, that plan means that bugs only appearing on special-case OSes like AIX, Solaris, OS/2, etc. probably don't have any way to be marked any more.
For example, when I currently see a compile bug reported on OS/2 and set to that OS/s, I know I probably don't need to care about it myself...

	Mark Banner (:standard8)
	Comment 15 • 14 years ago

(In reply to comment #14)
> Of course, that plan means that bugs only appearing on special-case OSes like
> AIX, Solaris, OS/2, etc. probably don't have any way to be marked any more.

I only said possibly excluding tier 3, if there's a valid case (which I think yours is), then we can include them.

We should definitely cut down on all the variants though, they feel like things that should be managed differently as they are much rarer IMO.

	:glob ✱ Assignee
	Comment 17 • 12 years ago

my preference to address this issue is (b) from comment 10:

- hide the hw/os fields from the guided form, and always set them to all/all
- change the wording on the advanced form to indicate these fields should only be
  set for platform specific issues, and default to all/all
- add a new field, reporter's ua, which will always be populate by the ua (if present).
- add a button on show_bug to set the hw/os fields from the reporter's ua using the
  current detection logic

	Gervase Markham [:gerv]
	Comment 18 • 12 years ago

That sounds like a good start, certainly :-)

Gerv

	:glob ✱ Assignee
	Comment 23 • 9 years ago

we should also allow per-product overriding of the default (eg. firefox-ios should default to all/ios) (from bug 1137411).

	:glob ✱ Assignee
	Comment 24 • 9 years ago

- adds a per-product default hw/os (can be "detect", or a value)
- stores reporter's user-agent in a new table
- updates to enter_bug:
  - changes label and layout to match show_bug's side-by-side display
  - replaces "your hardward/os has been detected" blurb with:
    Update the platform field if this bug is applicable to specific platforms.
  - adds "use my platform" button if the product's default is all/all
- updates to show_bug:
  - adds "from reporter" button to untriaged bugs if a reporter user-agent is available
    - untraiged bugs are UNCONFIRMED or in an "Untriaged" component

(note to self: schema changes, two-part deploy)

	Gervase Markham [:gerv]
	Comment 25 • 9 years ago

Is it possible with this patch for a product to opt out of HW/OS altogether? I.e. a special default value "don't show", which means the widgets don't even show up? I'm sure that would be popular in the non-code parts of BMO.

Gerv

	Dylan Hardison [:dylan] (he/him)
	Comment 26 • 9 years ago

Comment on attachment 8583593 [details] [diff] [review]
579089_1.patch

Review of attachment 8583593 [details] [diff] [review]:
-----------------------------------------------------------------

r- -- I'll change to an r+ if there's a justification for using $ENV{HTTP_USER_AGENT} directly. :)

::: extensions/BMO/Extension.pm
@@ +663,3 @@
>      }
>  }
>  

nit: I would probably factor out qw( default_platform_id default_op_sys_id ) as my @EXTRA_COLUMNS,
rather than repeating it all over, but then I soemtimes make typos... :)

@@ +823,5 @@
>          }
>      }
> +
> +    # store user-agent
> +    if (my $ua = $ENV{HTTP_USER_AGENT}) {

err, I guess you're doing this rather than Bugzilla->cgi->user_agent for performance reasons?

	:glob ✱ Assignee
	Comment 27 • 9 years ago

(In reply to Dylan William Hardison [:dylan] from comment #26)
> > +    # store user-agent
> > +    if (my $ua = $ENV{HTTP_USER_AGENT}) {
> 
> err, I guess you're doing this rather than Bugzilla->cgi->user_agent for
> performance reasons?

i mirrored how we collect it in Bugzilla::UserAgent.  looking over bugzilla we appear to use both methods.  yay.

	:glob ✱ Assignee
	Comment 28 • 9 years ago

(In reply to Gervase Markham [:gerv] from comment #25)
> Is it possible with this patch for a product to opt out of HW/OS altogether?

no; hw/os will still be present on all bugs.
doing that is a fair chunk of work and outside of the scope of this bug.

	:glob ✱ Assignee
	Comment 29 • 9 years ago

- switch from ENV to cgi
- fix button class following removal of in-page style

	Dylan Hardison [:dylan] (he/him)
	Comment 30 • 9 years ago

Comment on attachment 8590083 [details] [diff] [review]
579089_2.patch

Review of attachment 8590083 [details] [diff] [review]:
-----------------------------------------------------------------

r=dylan

	:glob ✱ Assignee
	Comment 32 • 9 years ago

oops, wrong bug.

	:glob ✱ Assignee
	Comment 33 • 9 years ago

following my post to dev.platform regarding this change, it was suggested that defaulting to "unspecified/unspecified" would be more valuable than "all/all".

Milan Sreckovic:
> If I was going with the “what can we do that’s fairly simple
> and improves things”, I’d create a new value for that field,
> “Not specified” (or something like that) and make that the
> default.  That way, we differentiate between the values that
> were explicitly set, in which case, I have to hope they will
> be more correct than they are today, and values that were
> just left at the default value.

Lawrence Mandel:
> +1 to Milan's suggestion. These fields are used somewhat
> consistently on stability and graphics bugs, which release
> management pays attention to. If we are going to continue
> with the fields, I like the idea of "Not specified" as that
> makes it clear that no value was set whereas "All" is
> currently used if the bug affects all platforms or if we
> don't know.

imho this makes a lot of sense and is hard argue against :)  unless there are any objections here i'll update this bug and the patch slightly to follow that change.

note: given "unspecified" is already used elsewhere on bmo, we should go with that over "not specified".

	:glob ✱ Assignee
	Comment 34 • 9 years ago

schema only:

To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   c4975b6..e9bfbbb  master -> master

	:glob ✱ Assignee
	Comment 35 • 9 years ago

and the rest:

To ssh://gitolite3@git.mozilla.org/webtools/bmo/bugzilla.git
   4aa44c4..5db6eeb  master -> master