On 18.03.2013 12:30, Joachim Dreimann wrote: > On 18 March 2013 10:14, Gary Martin <[email protected]> wrote: > >> On 18/03/13 09:26, Peter Koželj wrote: >> >>> On 18 March 2013 08:53, Branko Čibej <[email protected]> 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(!): > https://issues.apache.org/jira/browse/INFRA-5064 > > 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 | www.wandisco.com
