Standard bug entry form for non-canconfirm users is missing fields that are available from the guided form
Categories
(bugzilla.mozilla.org :: Bug Creation/Editing, defect)
Tracking
()
People
(Reporter: aoia7rz7l, Assigned: dkl)
Details
Attachments
(1 file)
In the last month or two I found myself no longer being able to fill in some of the optional fields when filing a bug report, and had to edit them in after I submitted it. At first I thought maybe they are locking down on users without special permissions, but then this week I can't even choose the version field for versions older than the current ESR when I was editing.
Turns out the first problem was caused by https://github.com/mozilla-bteam/bmo/pull/2132 (Bug 1549621) and the second by https://github.com/mozilla-bteam/bmo/pull/2178 (Bug 1877294). I can live with the former as long as the workaround continue to exist. The latter, well I am not too sure. I have got no qualms if they wanted to limit the Target Milestone field , but the Version field? If I were to quote from the Bug Writing Guidelines:
Version: select the earliest Version with what the problem can be reproduced:
Developers will use that information to narrow down the commit what introduced a regression
QA staff needs that information to distinguish bugs with similar symptoms, but different roots.
bugs that definitively appeared in different Product Versions probably will have different roots
But bugs that started with the same Product Version probably are DUPLICATEs
Trunk does not allow any useful query. We have Trunk version bugs from beginning of the project until today, no common characteristics at all what can be tagged with this version. Avoid Trunk, replace it by precise information with what version the problem appeared if you can.
so what was the rationale behind limiting the selection of older versions? At the very least they should limit it to the latest ESR version and not the last 10 releases, because that's what Mozilla support. Although they shouldn't have done that at all, because that's not what that field is meant for, unless someone feel like their documentation is out of date.
Personally I have found the Version field to be immensely useful when tracking down older bugs on bugzilla, and I also actively fill out that field whenever I have a precise regression range. It would be a shame to limit its effective use.
Speaking of Version, AFAICR I used to see a mixture of "XXX Branch" and "Firefox XXX"? And yet I only see "Firefox xx" in Version today and shortly before it was being limited to the last 10 releases. Some of the information in the github repo were also contradictory in terms of which one is which (e.g. https://github.com/mozilla-bteam/bmo/blob/master/scripts/generate_bmo_data.pl#L291-L303 and https://github.com/mozilla-bteam/bmo/blob/master/template/en/default/pages/new_release.html.tmpl#L74-L113). Are Version and Target Milestone being used interchangeably now?
|
Assignee | |
Comment 2•9 months ago
|
||
(In reply to aoia7rz7l from comment #0)
so what was the rationale behind limiting the selection of older versions? At the very least they should limit it to the latest ESR version and not the last 10 releases, because that's what Mozilla support. Although they shouldn't have done that at all, because that's not what that field is meant for, unless someone feel like their documentation is out of date.
Personally I have found the
Versionfield to be immensely useful when tracking down older bugs on bugzilla, and I also actively fill out that field whenever I have a precise regression range. It would be a shame to limit its effective use.
Actually looking at it again now, it does seem that omitting the version field for the standard bug form was an oversight on my part when reviewing the changes. The version field should not be limited to empowered users and is also available on the guide bug entry form. I will make sure that it gets added back to the standard form as well.
dkl
|
||
Comment 3•8 months ago
|
||
|
|
Assignee | |
Comment 4•8 months ago
|
||
Description
•