[Development] Closing Jira Bugs

[Alan Alpert]

On Wed, Jan 30, 2013 at 12:19 PM, Shaw Andy <Andy.Shaw at digia.com> wrote:
>> Op 30-1-2013 19:34, Robin Burchell schreef:
>> > On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada
>> > <san at sansano.inf.utfsm.cl> wrote:
>> >> How many changes do you need to close a jira task ? one, two, more, who
>> >> knows ?
>> > The person submitting the change.
>> >
>> > The way I've seen this done various other places is to stop trying to
>> > overload all bugtracker metadata into a single keyword ("Task-number")
>> > and instead split out the precise meanings ("Fixes" actually fixes it,
>> > "Addresses" works towards, but does not close - for instance).
>> Yep, I have seen that work rather well, on Assembla for instance. The
>> bugtracker gets a nice comment attached with a link to change
>> automagically, and if the magic keyword is used together with the bug
>> number, the status is modified automatically.
>>
>> I guess the trick for Qt would be though to make sure that the status is
>> only changed (to fixed) if the fix is merged in a branch that will
>> actually be released. Other commits with such a tag may get rejected
>> through Gerrit, or fail to integrate somehow, and that should not lead
>> to issues falsely reported as fixed in Jira of course.
>
> Just to muddy the waters here, but would it be possible to make sure it only does this when the patch integrates?  What happens if the bug is reopened because it turns out to be still be an issue?

The patch integrating isn't a guarantee the bug is fixed. Even the
developer submitting the change isn't always sure. The complete
process should involve a QA verification step before closing. But
since I don't think we have that, manual developer "verification" will
have to do.

To muddy the waters further, wasn't the problem being that the person
wanting the task closed wasn't the assignee? I thought the problem was
of the committer being a contributor who isn't an approver and so
can't take ownership of the JIRA task, and a reviewer who didn't know
they also should have managed the JIRA status. It seems odd that a
reviewer should assign the task to themselves as in progress if they
aren't actively working on it, just reviewing a patch, but that's my
current understanding of the process(which no-one adheres too, because
it's not very sensible).

--
Alan Alpert