Last Comment Bug 467711 - Allow for additional expanded description for Versions and Milestones
: Allow for additional expanded description for Versions and Milestones
Status: NEW
Product: Bugzilla
Classification: Server Software
Component: Bugzilla-General (show other bugs)
: unspecified
: All All
P4 enhancement with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: default-qa
Depends on:
  Show dependency treegraph
Reported: 2008-12-02 19:44 PST by Jeff
Modified: 2010-04-14 06:22 PDT (History)
2 users (show)
LpSolit: blocking3.2.1-
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Jeff 2008-12-02 19:44:37 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2008102920 Firefox/3.0.4 (.NET CLR 3.5.30729)
Build Identifier: Bugzilla 3.2

I think it would be beneficial to allow further descriptions for each Milestone and Version for each product just as we have for Classifications, Products, and Components. These descriptions could then be shown as tool-tips or on an extra page that details all Milestones or Versions.

My Personal Reasoning

After upgrading to Bugzilla 3.2 and switching to the Dusk theme an old problem has gotten worse in that when I do an advanced search the UI for the list boxes that represent the Classification, Component... all are so wide that a good portion of the UI is off of my page (resolution=1440x900). The reason why I wouldn't be completely satisfied with changes to the advanced search page to accommodate these large fields, which I do believe should be done as well, is that I realized that the fundamental reason why my fields are becoming so large is because of a lack of space to store extra information about each Version or Milestone. Take one of my examples where I have a version named "non-release (must specify revision and branch in comment!)". We need to specify some of our versions this way in order to work around the lack of proper branch tracking (bug#55970), but besides this fact it seems to me that simply specifying "non-release" for the version name and then instead giving this Version a description of "must specify revision and branch in comment!" would be much more sensible. 

If we allow expanded descriptions for Version and Milestone we then maybe the bug entry page could show the expanded descriptions when the corresponding item is selected just as is currently done in 3.2 when the user selects a Component.

With regard to having some kind of summary page as well, it may be useful to show users a list of all Versions and Milestones on a product along with whether they are disabled/retired since I've read that that is a feature that is also in the works.

Reproducible: Always
Comment 1 User image Frédéric Buclin 2008-12-03 08:52:07 PST
A new feature cannot block a release.
Comment 2 User image Jeff 2008-12-04 12:16:54 PST
How can I request this feature for consideration in Bugzilla 4.0?
Comment 3 User image Jeff 2008-12-17 08:03:42 PST
Today I took a look at what Trac, which I consider to be the most reasonable alternative to Bugzilla for our company, and I was excited to see that both Milestones and Versions in Trac not only have a description field but it also accepts wikiformatting and there are also attached date fields.

At the same time this is sort of disappointing since Bugzilla has been around for much longer than Trac and they are already implementing these types of features which seem to be very basic. Are there specific reasons such as scalability for why milestones and versions were not created with extended descriptions and date fields in mind?
Comment 4 User image Jeff 2008-12-17 08:04:58 PST
As a followup to comment#3, you can play around with Versions and Milestones in the the Trac demo site by following the links below.
Comment 5 User image Jeff 2010-04-13 20:23:22 PDT
The original links I had posted in comment#4 are broken. The link below is to a working demo although it doesn't appear to have admin access to show how versions and milestones can be setup in trac.

Note You need to log in before you can comment on or make changes to this bug.