[gmx-developers] Development Communication Tools, was: Python interface for Gromacs

[Mark Abraham]

----- Original Message -----
From: Szilárd Páll <szilard.pall at cbr.su.se>
Date: Friday, September 10, 2010 9:54
Subject: Re: [gmx-developers] Development Communication Tools, was: Python	interface for Gromacs
To: Discussion list for GROMACS development <gmx-developers at gromacs.org>

> I also strongly support issue tracking systems. Most 
> importantly, a
> well set up system with bugs, features, roadmap, wiki, etc. as
> integrated and as straightforward to use as possible - pretty much
> what Teemu suggested. The problem I see with the current setup 
> is that
> there is a very loose (in some case almost no) integration between
> bugs/features and their assignments to developers, git, etc.
> 
> Although I don't have deep experience with any of the systems, I've
> heard good things about Trac and Redmine. However, switching to 
> any of
> them would of course require a bit of effort - though it very well
> might pay off.
> 
> Otherwise, getting Bugzilla a bit in shape could also help a 
> lot, for
> instance git integration (http://www.theoldmonk.net/gitzilla) would
> save a lot of headache.

There's a scarcity of information there about what Gitzilla actually does. One of his early blog posts (http://www.theoldmonk.net/blog/archives/2008/03/08/git-bugzilla_integration/) says

"Anyhoo - here's what I want : 
 1. Git should disallow any commit where the commit message does not have  a bug number. 
 2. Git should add a comment to the corresponding bug on a commit,  mentioning the author, the Trac changeset link, the commit message and  the list of files which changed."

and then provides some early drafts of git hook scripts to do it.

Read simply, that's too restrictive. You have to be able to create local commits to suit your own workflow. If what this means is that you can't push commits to the central repo without a bug number, now we're talking. For one-commit fixes that's easy. Ongoing development of a feature should be on its own branch with its own set of bugzilla numbers (development and bugs), so that merges into master or release-x-x-patches will have the desired automated linking.

This way, when (say) there's been some discussion between users and devs about fixing a bug, and the resulting commit broke something else down the line, there's a way for the person re-fixing it to know to revisit the prior discussion.

There would have to be open bugs for trivia like spelling fixes, formatting fixes, removing C++-style comments, etc.

Bugzilla comments are a bit too primitive for planning and documenting ongoing development. You can reply to a previous comment and get an email-style quoted copy to refer to, but once you've started a comment, you can't add an attachment to it in the same way you could with an attachment to the original report. I think something more wiki-like could be preferable. However, the existing knowledge of how Bugzilla works is a valuable commodity that we don't want to throw away lightly. Are there upgrades to Bugzilla available?

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20100910/04ac734a/attachment.html>