Closed Bug 1471887 Opened 6 years ago Closed 6 years ago

Evaluate if the Version: field for Firefox is still useful

Categories

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

Production
task
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: Sylvestre, Unassigned)

References

(Blocks 1 open bug)

Details

Reporting this bug to start a discussion and keep trace of that. The more I look at the "Version:" field, the more I realize that it is: * a duplicate of the Firefox status flag * unmaintained * misleading (is that the first occurrence of the issue or the last known occurrence) Maybe it is time to kill it?
I'm always here for getting rid of redundant metadata. Version is also inconsistent across products as an artifact of the previous platform/Firefox split. Some thoughts I have: * If we relied on the status_firefoxNN field instead of version, how would we handle the case were we discover a bug in a version, and fix it in the same version, such as a bug found in nightly and fixed in the next build, or a bug found in Release and fixed in a point release of the same version? We'd only see status_firefoxNN = fixed, and would have to infer it was discovered and fixed in version NN. * The above could probably be handled if we made another tracking flag per version with values: "---" "?" "affected" "unaffected" and moved "affected" and "unaffected" out of status_firefoxNN? An advantage to this is that we could fix the issue where version is a property of products, but tracking flags can be associated with multiple products and components. * We only keep the current Nightly, Beta, Release, and ESR versions of the status_firefoxNN field present when filing a new bug. If we find that a bug has been around since an earlier release version, how would we register that? * Status fields are not obvious when creating or editing bugs, and they'd need higher prominence * I think, in order to be consistent, we'd have to backfill the status_firefoxNN flag. * What tools do we need to fix? * What non firefox things use version that we'd need to replace. * Let's replace milestone while we are at it. * So I'd suggest an initial proposal: Replace Version with a new tracking flag: affected_firefoxNN There will be an affected_firefoxNN for each version of firefox, with values `---`, `?`, `affected`, and `unaffected`. We would backfill this for previous versions of Firefox, using the Version field's value, or the value of status_firefoxNN if it is one of `---`, `?`, `affected`, or `unaffected`. The status flag's value has priority over Version. Replace Target Milestone with the status_firefoxNN field. We would backfill pre-status_firefoxNN versions with this field and use metadata to fill this in (this may let us consolidate a bunch of obsoleted, no-longer used fields.) If the value of status_firefoxNN is one of `---`, `?`, `affected`, or `unaffected`, then we set affected_firefoxNN to that value and set status_firefoxNN to `---`. We remove `---`, `?`, `affected`, and `unaffected` from the list of values for status-firefoxNN. Let me know what you think, and then I'd like to bring in more people to the discussion.
Flags: needinfo?(sledru)
I think I was incorrect (thanks Julien Cristau for mentioning that) Instead, I think we can have automation to flag inconsistencies between Version & status flags. I will give a try using autonag. As Julien also mentioned to me, version is the only way we have to flag in which versions a regression started to occur. Maybe Target Milestone is useless ?
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(sledru)
Resolution: --- → INVALID
See Also: → 1472595
You need to log in before you can comment on or make changes to this bug.