Comment style for bug fixes?

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.

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.

Peter

Comment style for bug fixes?

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 ...

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-c...)
S

Comment style for bug fixes?

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