On Tuesday 31 May 2011 00:35:59 Stephen Roderick wrote:
> On May 30, 2011, at 18:09 , Peter Soetens wrote:
> > On Sun, May 29, 2011 at 9:07 PM, S Roderick <kiwi [dot] net [..] ...> wrote:
> >> What style are we using, particularly when it comes to bug fixes? Most
> >> of our comments are of the form (subsystem: comment) e.g.
> >>
> >> logging: rewrite streaming to allow formatting
> >> scripting: provide property to disable the zero period warning.
> >>
> >>
> >> But what about bug fixes? We've got
> >>
> >> #789: Add test case for rt_string use in state machines
> >> useorocos: fix bug #856 regarding .pc include path in ros environments
> >> lockfree: fix bug #852: Bug in DataObjectLockFree (missed data
> >> initialization leading to malloc when using std::vector data)fix bug
> >> #849: Attribute::get doesn't work anymore over CORBA. Refs #846:
> >> Initialize TLSF memory pool in remaining unit tests
> >> Fixes #836: Test timeout ignored by ctest
> >>
> >> Let's choose one for consistency's sake, and I'll document it on the
> >> website.
> >
> > These are normally structured to inform the bug tracker that the fix
> > was applied. Since we use Bugzilla, it probably should be in a form
> > that bugzilla understands.
>
> +1
>
> > I've found two things: gitzilla (http://www.theoldmonk.net/gitzilla/)
> > and git-bz (http://git.fishsoup.net/man/git-bz.html ). The latter
> > looks much more mature, but requires you to use the git bz commands
> > instead of the classic git commands. The former uses server-side
> > commit hooks, but I don't think it's that well worked out.
>
> We use the last two styles (those are my commits) as the Redmine issue
> tracking tool swallows these directly.
>
> So those git bz commands need to be done on the developer's side?!?! Do
> _not_ like the sound of that ...

I do :-) The centralised way of server-side commit hooks comes from the age of
centralised vcs. git-bz offers you to manipulate bugzilla (attach patches for
testing) without pushing them to a public server first. It's lightweight and
the configuration is on a per-repository basis.

>
> The first one is the more common. Have a commit hook deal with the incoming
> commit and inform other interested parties (we do this for automated
> builds). That seems a lot less error prone ... but we'd have to figure out
> how to integrate that with gitorious (which it appears isn't offered ...
> http://stackoverflow.com/questions/1913726/has-gitorious-hooks-for-cia-com
> mit-notification) S

I'm testing it right now with a few bug reports and I like it already :-)

My setup in the RTT git repository:

git config bz.default-tracker bugs.orocos.org
git config bz.default-product Toolchain
git config bz.default-component RTT
git config --global bz.browser chromium

I'm trying the mozilla clone of it since it includes patches I like too:
https://github.com/bholley/git-bz-moz.git

but I'm still evaluating... as you can see :-)

Peter