GNOME Bugzilla – Bug 681607
clarify version fields
Last modified: 2015-02-11 02:59:17 UTC
It has been requested that submitters more consistently set the Version field on bugs. This seems like a good goal. However, this is a bit confusing from the submitters point of view for a few reasons. Problems 1. Many products have non numerical version numbers listed which are basically catch alls. "trunk" "git master" "head" etc. 2. Different products have different versions listed in the dropdown 3. I have to do a lot of work to set the version field 4. While they aren't shown on the new bug page, if you forget to set the version at bug creation and want to do it later there are too many version / milestone options and it is hard to know what to use: version, target milestone, gnome target, gnome version. Recommendations 1. These should be removed. 2. We should ensure all products have consistent version lists. 3. We should display version numbers in reverse order with most recent at the top. And "Unspecified" at the very top. Longer term it would be nice to hook up autodetection like we have on the shell extensions site. 4. Remove "Target Milestone" and "GNOME version" unless a maintainer needs them. Most don't. Fix the name of "GNOME target" -> "GNOME Target".
(In reply to comment #0) > Recommendations > 1. These should be removed. This is very hard because we have lots of old tickets with these versions set. We could destroy information by e.g. resetting them all to something like "unspecified" though. > 2. We should ensure all products have consistent version lists. That would first require to have a constant versioning system across all products listed in GNOME Bugzilla which I also consider rather impossible. We encourage using the GNOME version (like currently 3.5.x for an unstable recent release) but it's mostly up to maintainers (e.g. GtkHtml has 4.5.x already, or Glib is still in its 2.x life). > 3. We should display version numbers in reverse order with most recent at the > top. And "Unspecified" at the very top. Longer term it would be nice to hook up > autodetection like we have on the shell extensions site. Clear +1. > 4. Remove "Target Milestone" and "GNOME version" unless a maintainer needs > them. Most don't. Fix the name of "GNOME target" -> "GNOME Target". I don't see much sense for GNOME version either. TMs really depend on the specific maintainers of a module, maybe we could hide them if they are clearly not in use, or provide a checkbox per module in its administration settings.
Just to clarify. By remove, I mostly mean remove from the interface :). Or at least for new reports.
> 1. These should be removed. From Bugzilla 4.2 on you can disable specific versions: For existing reports nothing changes, but for newly created reports such a version cannot be set anymore. That sounds like a good way to go.
Setting TM to 4.4 because some stuff (disabling older versions) is possible in 4.4, however this ticket has too many separate items to be entirely actionable.
An entertaining list of non-numeric version names in GNOME Bugzilla (though some might come from disabled products), just to show that this might be slightly complexer: bzr trunk current Current SVN cvs CVS CVS (HEAD) CVS (head) cvs (head) CVS gconf-1-0 CVS HEAD CVS head CVS latest devel development (SVN TRUNK) Future Git git GIT git-maint git-master git 0.4-branch GIT HEAD git head Git Master GIT master Git master git master git master (2.0.0) HEAD head HEAD CVS latest Legacy Branch mainline master master/HEAD not applicable Not Applicable Old older-than-dirt prehistoric Really Ancient SVN svn head SVN HEAD SVN trunk SVN TRUNK SVN Trunk svn trunk svn/bzr repository trunk Trunk undetermined unknown Unmaintained unspecified WISHLIST
https://mail.gnome.org/archives/desktop-devel-list/2015-January/msg00072.html : Products in GNOME Bugzilla's {Core, Platform, Bindings, Applications} classifications now all use "git master" (or a case variation like "Git master") in the "Version" field for "latest dev code, not expressed via some version number". 1. and 3. will be up / can be done by maintainers once we have 4.4 in place as 4.4 will allow disabling certain version field entries so they are not offered anymore for setting them in show_bug.cgi and enter_bug.cgi. They will still be available in query.cgi. This makes this ticket WORKSFORME once 4.4 has been deployed.
(In reply to William Jon McCann from comment #0) > Problems > 1. Many products have non numerical version numbers listed which are > basically catch alls. "trunk" "git master" "head" etc. > 2. Different products have different versions listed in the dropdown > 3. I have to do a lot of work to set the version field > 4. While they aren't shown on the new bug page, if you forget to set the > version at bug creation and want to do it later there are too many version / > milestone options and it is hard to know what to use: version, target > milestone, gnome target, gnome version. > > Recommendations > 1. These should be removed. Since BZ 4.4, maintainers of products can disable these versions for newly created tickets. This is up to maintainers. If anyone is interested in pushing some policy, this should be brought up on d-d-l instead. > 2. We should ensure all products have consistent version lists. That is again a social policy for naming conventions and cannot be handled by some Bugzilla code or taxonomy changes. > 3. We should display version numbers in reverse order We cannot until https://bugzilla.mozilla.org/show_bug.cgi?id=65317 is fixed > 4. Remove "Target Milestone" and "GNOME version" unless a maintainer needs > them. Most don't. Fix the name of "GNOME target" -> "GNOME Target". GNOME version is covered in bug 725050. Custom hack for "Target Milestone" could be written by anybody who feels like, in a dedicated ticket. Upstream Bugzilla has feature creep and someonc could potentially deal with that as part of bug 743027. Closing this ticket as WONTFIX; too many different things in one ticket.