Show bug tags in "Changes" view

Bug #735289 reported by Craig Hewetson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
loggerhead
Triaged
Wishlist
Unassigned
loggerhead-breezy
Triaged
Wishlist
Unassigned

Bug Description

The most important thing that our software managers would like to see in loggerhead is the bug fixes for a particular branch, without having to click on each and every revision to look through the details. (as in qbzr's qlog dialog)

So basically this is a feature request for showing the bug (--fixes) tags on the "changes" table/grid. Currently I have to get the manager's to install bazaar and qbzr on their machines to view the bug fixes on specific branches, which is a pity because it would be much better if they could just use the web interface to achieve this.

Thanks

Changed in loggerhead:
status: New → Confirmed
Revision history for this message
John A Meinel (jameinel) wrote :

Looking here: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/5718.5.7
The data is available in the specific revisions.
The change requested here looks like it would just require tweaking loggerhead/controllers/revlog_ui.py and loggerhead/templates/revlog.pt

Not particularly hard, but you'd want to figure out how you want it formatted, etc.

An alternative is to always show it, like Tag gets shown if any revision has a tag on it.

Note that if you are using a merge based workflow, it is possible that the revision which has the --fixes commit, is a merge commit, and not the mainline being show by loggerhead.

Changed in loggerhead:
importance: Undecided → Wishlist
status: Confirmed → Triaged
Revision history for this message
Craig Hewetson (craighewetson-deactivatedaccount) wrote :

When it comes to "merge commits" where bug tags would be hidden from the mainline (if the revision "node" isn't "expanded").
I suggest that the all bug --fixes that occurred in "sub" revisions be shown next to the particular revision shown in the mainline (the revision where the branch was merged and committed ).

So just by looking at the mainline the user can see all the fixes that took place without clicking or expanding revisions etc. Also once the "merged committed" revision is expanded then those bug tags can then be shown alongside the "more" correct revision where the bug was actually fixed...

ie:
Mainline fully "collapsed":

r101 bug #1234 bug #222 bug#33
 |
r100
 |
r99

now expand revision r101:
r101
        \
        r100.3 bug #1234
         |
        r100.2 bug #222
         |
        r100.1 bug #33
     /
r100
  |
r99

Not sure if I'm making sense here :)

Revision history for this message
Craig Hewetson (craighewetson-deactivatedaccount) wrote :

Also bug tags can be decorated slightly differently to indicate if they "exactly" apply to their corresponding revision or not.

Assuming a similar decoration is used as in Qbzr's qlog. Then when the bug tag exactly applies to the revision then it can be dark red, this senario applies to the "expanded" state of my text graph above.
If its partially applied to a revision as in the state before the expansion took place then the bug tags can then be decorated with a lighter red etc, indicating that there are bug fixes in this revision but as a result of a merge etc.

Jelmer Vernooij (jelmer)
Changed in loggerhead-breezy:
status: New → Triaged
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.