[gmx-developers] some notes on using redmine

[Mark Abraham]

On 10/01/2011 9:24 AM, Szilárd Páll wrote:
> The problem is that either we have to assume that _every_ commit (at
> least in the master and release branches) is a bugfix or feature --
> and therefor it is filed in redmine which IMHO would be a pain to live
> with, or it is up to the developers' discipline to remember when to
> file a bug report or register a feature in redmine.
>
> I don't think that hooks can address this issue.

Agreed. I'm certainly not envisaging hooks creating Redmine issues. I'd 
be hoping that developers' discipline and judgment was good enough for 
things to work reasonably well with (say) only a gentle reminder in the 
commit message template (suggestion available for comment here 
http://redmine.gromacs.org/issues/648#note-3). There will be cases of 
developers forgetting, or not expecting an issue was going to arise in 
the future, and Redmine issues can be created that link those commits - 
the only loss is that the message of a pushed commit can't have an issue 
ID retroactively embedded.

Mark

> On Sat, Jan 8, 2011 at 9:58 PM, David van der Spoel
> <spoel at xray.bmc.uu.se>  wrote:
>> On 2011-01-08 20.36, Teemu Murtola wrote:
>>> On Fri, Jan 7, 2011 at 01:56, Mark Abraham<Mark.Abraham at anu.edu.au>
>>>   wrote:
>>>> I think it would be overkill to require the creation or linking of a
>>>> Redmine
>>>> issue for every commit, however. Thoughts?
>>> Requiring it could indeed be overkill, but we could try to make it a
>>> strong recommendation.  This way, Redmine would get much more easily
>>> integrated into the workflow, because people would be forced to think
>>> about the issue at least a bit.  Adding something like IssueID #NNN at
>>> the end of a commit message should be enough (or perhaps configuring
>>> Redmine such that it would link commits that start with [#NNN]) in
>>> cases where the issue number does not naturally fit into the commit
>>> message.
>>>
>>> Another thing that would be worth thinking about is the formatting of
>>> the commit messages.  Many git tools, and it seems that Redmine as
>>> well, work somewhat better if commit messages are formatted according
>>> to the guidelines put forth in many git tutorials: first a max
>>> ~50-char line with a short summary, then an empty line, and then a
>>> more detailed description of the commit (many places suggest max 72
>>> character lines, and, e.g., gitk works badly with long lines).  If
>>> nothing else, this would make the activity page in Redmine more
>>> readable.
>>>
>> It would be great if this kind of thing were not dependent on the memory of
>> developers. Many of us (at least I) put in a patch now and then and have a
>> hard time remembering such guidelines. Is there a way we can enforce a
>> certain format?
>>
>>
>>
>>
>>> Teemu
>>
>> --
>> David van der Spoel, Ph.D., Professor of Biology
>> Dept. of Cell&  Molec. Biol., Uppsala University.
>> Box 596, 75124 Uppsala, Sweden. Phone:  +46184714205.
>> spoel at xray.bmc.uu.se    http://folding.bmc.uu.se
>> --
>> gmx-developers mailing list
>> gmx-developers at gromacs.org
>> http://lists.gromacs.org/mailman/listinfo/gmx-developers
>> Please don't post (un)subscribe requests to the list. Use the www interface
>> or send it to gmx-developers-request at gromacs.org.
>>