On Wed, Jan 30, 2013 at 12:19 PM, Shaw Andy <[email protected]> wrote: >> Op 30-1-2013 19:34, Robin Burchell schreef: >> > On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada >> > <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
