Bug tracker association improvement

Martin Pool mbp at sourcefrog.net
Wed May 13 09:02:28 BST 2009


2009/5/12 Jean-Baptiste Crouigneau <jbcrouigneau at yahoo.com>:
> Hi everybody!
>
> My first, and hopefully not my last post... :)
>
> Martin kindly adviced me to post here my remarks about bug trackers integration
> with bazaar.
> The --fixes option is a very good thing, but as mentioned in documentation has
> some limitations.

Hello Jean-Baptiste, welcome,

> If I understood well how it works, my requests would be :
>
> 1- Make this option a requirement : not for all projects of course, but could be
> configurable. No commit allowed wihtout a bug or task ID (would be a standard
> for me).

This would make sense as a commit hook, controlled by a per-location
configuration setting saying whether a bug is required.  If you'd like
to try this you can use the code in https://launchpad.net/bzr-email as
an example, and ask here if you have any technical questions.

I think some people might like to turn this on only for eg mainline
commits, because people may make incremental commits not related to
any particular bug, depending on their organization's process.

> 2- What happens if bug/task ID is wrong? The only way to avoid that is to check
> the ID with bug tracking tool (and by the way, check also the status?). But
> bazaar is to be used offline... Maybe, if bug/task ID is required, check this
> when pushing commit to central location, and reject commits with bad bug/task ID
> (meaning you must be able to correct it...).

I think a good way to tackle this would be to extend the bug-tracker
interface in bzr to have the concept of checking on the existence and
state of a bug number.  Then you could hook this up either at commit
time or during push, and it might be useful just to show the summary
of the bug.

>
> 3- My last wish is not compliant with bazaar core concepts, but I put it anyway,
> who knows, could lead to a new feature in the future... :)
> My idea is to specify why you are going to change a file before to make the
> change... Some VCS require a checkout file by file. Then, you can specify
> bug/task ID in checkout command (or even make it a requirement). You can even
> checkout a file twice, for two different bug/task (not recommanded but possible
> with local merge).

The idea of saying "I'm starting work on this bug" is an interesting
one that has come up several times.  One approach is to just post a
note to the bug semi-automatically when you make the branch.  On
Launchpad you could for instance associate the bug with the branch
when you first push the branch - I think there is a WSDL api for this
and a web UI but nothing in bzr.

> The aim is not to control multiple checkout of one file by several developpers,
> but to compel developpers to associate each change to a task or a bug.
> You can then checkin (or revert) changes linked to one task/bug, ignoring other
> changes.
> It leads to a better management of the work, of the changes, a real "task
> oriented" workflow.
>
> I also have to mention I'm (personnaly) not a fanatic of automatic update of
> taks/bug status when commiting. Then, you can commit several times for a task or
> a bug (and several developpers can work on a same task/bug). The only limitation
> should be that the task/bug has to be "open" (or any equivalent state) to accept
> a new change.
>
> I don't know if all this can interest a lot of body, but with bazaar gatekeeper
> feature, it would be my "dream" workflow.
> There is a tool (not free...) that propose equivalent features : Synergy (now
> owned by IBM). Maybe not the best tool, but I used it a few years ago and had a
> good experience with it.
>
> My two cents!

Thanks for your thoughts.

-- 
Martin <http://launchpad.net/~mbp/>



More information about the bazaar mailing list