[guardian-dev] git+redmine workflow idea for handling closing issues

Hans-Christoph Steiner hans at guardianproject.info
Thu Dec 12 10:42:07 EST 2013



On 12/12/2013 09:45 AM, Nathan of Guardian wrote:
> On 12/11/2013 11:15 AM, Hans-Christoph Steiner wrote:
>> It might make sense to manually set the issue to Resolved once the person
>> coding it thinks its done.  That person would then include "closes #1234" in
>> the commit message.  Then after another dev on that project reviews the commit
>> and pushes it to the main upstream git repo, redmine would get the commit and
>> close the issue.
> 
> I see "close" as not a development activity, but as a project manager
> and/or QA activity. No activity from Git should ever result in a ticket
> being closed. A human should manually do it after verifying the commit
> does resolve the issue.
> 
> +n

I agree, with this idea, the human intervention is when the reviewing dev
pushes the commit to the upstream repo.  I suppose this doesn't cover external
bug reports well though, where the reporter of the bug should declare it
closed.  My experience with various projects and bug trackers has shown me
that reporters of bugs most of the time don't ever return to post anything on
their issue.

One thing that I really like in SourceForge's bug tracker is the "Pending"
status.  It is very useful for when you think you fixed a bug and you want
feedback.  When an issue is set to Pending, it will close automatically in 2
weeks if there was no other discussion on the issue.  Any change in the issue
cancels the Pending status.  This works great for getting feedback from bug
reporters.

.hc

-- 
PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B BE81


More information about the Guardian-dev mailing list