'bzr commit --fixes' should have better documentation

Bug #120050 reported by John A Meinel on 2007-06-12
14
Affects Status Importance Assigned to Milestone
Bazaar
Medium
James Westby

Bug Description

We implemented support for adding meta-information to a commit with '--fixes'. However, the documentation on how to use it is fairly sparse (bzr help bugs is very terse).

We should have a clear document of how to set up a bug tracker so that bzr knows what "bzr commit --fixes project:10" means.

John A Meinel (jameinel) on 2007-06-12
Changed in bzr:
importance: Undecided → Medium
status: Unconfirmed → Confirmed

I'm interested in taking this one on. I've found this page (http://doc.bazaar-vcs.org/latest/en/user-guide/bug_trackers.html) from the user guide that explains how to use it for bugzilla and trac, but I can't find any resources for getting it to work with Launchpad.

On (12/09/07 13:44), Mat Steeples wrote:
> I'm interested in taking this one on. I've found this page (http://doc
> .bazaar-vcs.org/latest/en/user-guide/bug_trackers.html) from the user
> guide that explains how to use it for bugzilla and trac, but I can't
> find any resources for getting it to work with Launchpad.

You just use

   bzr commit --fixes lp:12345

there is no set up required for launchpad as there is only one instance.

Thanks,

James

--
  James Westby -- GPG Key ID: B577FE13 -- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256

Daniel Finnie (danfinnie) wrote :

Hi,

I know this is a late comment but the only way that I found at that launchpad required the lp: at the start of the bug number is thru the comment above.

Maybe a link should be added from the bzr help commit page to bzr help bugs and the bzr help bugs page would say that lp: describes a launchpad bug.

Dan

Monty Taylor (mordred) wrote :

Me too.

From the --help text it seems that a bug id would be acceptable. I tried:

bzr commit --fixes=252805

Which did not do anything and gave this error:

bzr: ERROR: Invalid bug 252805. Must be in the form of 'tag:id'. Commit refused

With no explanation of what "tag" and "id" might be.

John A Meinel (jameinel) wrote :

We certainly could change the term "tag" to "tracker" which is a bit more appropriate. I looked into writing a patch which could add "bzrlib.bugtracker.tracker_registry.keys()" to the output, except that doesn't quite work.

The problem is that the tracker registry lists the tracker kind (like Launchpad, Bugzilla, etc) but not the *instance* (mozilla's Bugzilla instance, etc.)

For some single-instance trackers like Launchpad, we could check from the Tracker object directly. However, others are explicitly configured, (possibly as per-branch values). For example, bugzilla instances are registered as:

bugzilla_moz_url = XXXX

and then you can use "bzr commit --fixes moz:1233245"

And the user has control over what branches see what abbreviations.

So we would have to extend the existing Trackers to probe the branch configuration and see what trackers have been registered by the user.

Certainly possible to do, but not quite trivial.

In the short term, would the attached patch have helped? It at least gives an example.

James Westby (james-w) on 2008-07-29
Changed in bzr:
assignee: nobody → james-w
status: Confirmed → In Progress

John A Meinel wrote:
> We certainly could change the term "tag" to "tracker" which is a bit
> more appropriate. I looked into writing a patch which could add
> "bzrlib.bugtracker.tracker_registry.keys()" to the output, except that
> doesn't quite work.
>
> The problem is that the tracker registry lists the tracker kind (like
> Launchpad, Bugzilla, etc) but not the *instance* (mozilla's Bugzilla
> instance, etc.)
>
> For some single-instance trackers like Launchpad, we could check from
> the Tracker object directly. However, others are explicitly configured,
> (possibly as per-branch values). For example, bugzilla instances are
> registered as:
>
> bugzilla_moz_url = XXXX
>
> and then you can use "bzr commit --fixes moz:1233245"
>
> And the user has control over what branches see what abbreviations.
>
> So we would have to extend the existing Trackers to probe the branch
> configuration and see what trackers have been registered by the user.
>
> Certainly possible to do, but not quite trivial.
>
> In the short term, would the attached patch have helped? It at least
> gives an example.

Yes. The patch would have made the general case clearer. Then if I
wanted to figure out how to deal with different trackers, I could do
that. I'm not sure bzr commit needs to be able to show available
trackers... but perhaps there should be a different command to get a
list of configured trackers?

James Westby (james-w) on 2008-07-29
Changed in bzr:
status: In Progress → Fix Committed
Martin Albisetti (beuno) wrote :

I just spent a few minutes trying to figure out what --fixes wanted.
What was the fix for this bug?

James Westby (james-w) wrote :

On Sun, 2008-09-28 at 21:43 +0000, Martin Albisetti wrote:
> I just spent a few minutes trying to figure out what --fixes wanted.
> What was the fix for this bug?
>

I've got a merge request that I need to modify according to review
feedback. That should hopefully make it more clear what --fixes
wants.

Thanks,

James

Neal McBurnett (nealmcb) wrote :

I was also confused by the documentation and behavior.

I didn't even notice the information added to the bug and the trunk page after pushing a commit that used --fixes.

E.g. to
 https://bugs.edge.launchpad.net/electionaudits/+bug/278330
this was added:
  "~nealmcb/electionaudits/trunk (New) - Fix Available "
but no email was sent to bug subscribers about that major piece of news.

When I clicked on Fix Available, and hit "update", thinking that it would update the bug status to Fix Available, hopefully with some helpful default text, instead nothing happened.
When I clicked on Fix Available and typed some text, and hit "update", again the bug status wasn't changed,
and a bit of information was added. So I guess that is what bug-branches are.

I don't see this doc, referred to earlier:

 http://doc.bazaar-vcs.org/latest/en/user-guide/bug_trackers.html

But I was confused by what I did find in http://doc.bazaar-vcs.org/bzr.1.6/en/tutorials/using_bazaar_with_launchpad.html#changing-the-state-in-launchpad-while-committing-in-bazaar

this seemed to me to mean everything would be taken care of: "changes the State of the bug-branch relationship to Fix Available". But I clearly didn't understand what a bug-branch relationship was. So clarifying what _doesn't_ happen would help. The rest of that section seems designed to do so, but uses different terms like "close a bug" which I took to mean another subtlety. So I guess --fixes _creates_ the "bug-branch relationship".

Vincent Ladeuil (vila) wrote :

James, any feedback on this ? It doesn't seem to have landed...

James Westby (james-w) wrote :

On Wed, 2009-04-29 at 11:03 +0000, Vincent Ladeuil wrote:
> James, any feedback on this ? It doesn't seem to have landed...

I was sure that I updated the branch, had it approved, and submitted
it, but I can't find any evidence of that now. I'll see if I at least
did the first part.

Thanks,

James

James Westby (james-w) wrote :

On Wed, 2009-04-29 at 11:31 +0000, James Westby wrote:
> On Wed, 2009-04-29 at 11:03 +0000, Vincent Ladeuil wrote:
> > James, any feedback on this ? It doesn't seem to have landed...
>
> I was sure that I updated the branch, had it approved, and submitted
> it, but I can't find any evidence of that now. I'll see if I at least
> did the first part.

I think

revno: 4109 [merge]
committer: Canonical.com Patch Queue Manager <email address hidden>
branch nick: +trunk
timestamp: Wed 2009-03-11 01:17:43 +0000
message:
  (jamesw) Improve the help topic and errors around --fixes.

is it, though I can't find any evidence of it in the mailing list
archives.

Thanks,

James

Changed in bzr:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers