bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <>
Subject Re: Development and release process
Date Mon, 18 Mar 2013 16:54:37 GMT
On 18.03.2013 12:30, Joachim Dreimann wrote:
> On 18 March 2013 10:14, Gary Martin <> wrote:
>> On 18/03/13 09:26, Peter Koželj wrote:
>>> On 18 March 2013 08:53, Branko Čibej <> wrote:
>>>  On 18.03.2013 06:56, Peter Koželj wrote:
>>>>> [...]
>>>> There is nothing wrong with using issue trackers to track bugs, or even
>>>> tasks. I myself have used issue trackers as a project management tool --
>>>> but in different circumstances.
>>>> Let me try to give a concrete example: This community has decided to
>>>> introduce "Bloodhound enhancement proposals" as a formalized procedure
>>>> for defining and accepting feature definitions. Fine. But, why then,
>>>> once the feature has been designed and documented, take the extra step
>>>> of breaking it down into separate tasks and creating tracker entries for
>>>> those -- instead of just writing code? The exact same level of oversight
>>>> can be achieved, with much less context switching and overhead, simply
>>>> by writing informative log messages -- which are, IMO, a lot more useful
>>>> to someone who tries to understand the reasoning behind a certain piece
>>>> of code from commit history.
>> I can't deny that last bit of logic as it is a bit self referential. Yes,
>> we want to see good log messages to enable scrutiny through the log.
>> However, we should also benefit through linking commits to a ticket which
>> is an easier way to put a change in context. A commit message is often
>> going to be more about what happened than why.
> Ok, so my suggestion would be that whenever a commit message mentions a
> ticket, it gets added to the ticket as a comment.
> - Poor commit messages get more exposure that way
> - It encourages people to refer to tickets providing more context ( NOT a
> substitute for a good commit message)
> - Developers don't need to also add a comment to Bloodhound directly, the
> commit message will do.

This sounds like something BH should automate, post 1.0 :) I bet there
are already Trac plugins for that.

> For that Bloodhound would need some awareness of the repository; that has
> never been available since we started the project, and has been an open
> Jira ticket since last July(!):
> Greg and Brane, how do you suggest we can get progress on this? We've
> followed up on this quite a few times: via IRC, email and in board reports.
> Gary has also just raised the priority.

How hard, exactly, would it be to teach BH to look at remote
(Subversion) repositories? I know that the current SVN repository
connector requires that, but I haven't been able to figure out how
deeply ingrained in Trac is the assumption of local access.

-- Brane

Branko Čibej
Director of Subversion | WANdisco |

View raw message