Re: [Development] Closing Jira Bugs
On Jan 30, 2013, at 11:07 PM, Richard Moore r...@kde.orgmailto:r...@kde.org wrote: On 30 January 2013 20:24, Alan Alpert 4163654...@gmail.commailto:4163654...@gmail.com wrote: 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). I think a significant problem in this area is that we don't really have any guide on how to use the bug tracker that I'm aware of. I'd say I'm probably one of the non-digia, and non-nokia contributors who's kept up with qt development most and I haven't a clue how I should interact with it. Every so often I notice a bug that I or someone else has already fixed so I close it, but that's about it. If we want a policy on how to use it then fine, but it needs to be written down. If someone has written something down, then please tell me where it is so I can read it. We should probably look at the workflow on a more general basis and try to figure out whether it suits our needs. The manual verification step doesn't really work without a large QA team behind, so maybe the bugs should get closed automatically once they landed in the proper branches. But we currently have few people who can do these changes in Jira. Maybe that's something to look into with an small group during the next contributor summit. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
For now I'll go the add a comment in jira and hope that the assignee closes the task route.I don't have the privileges to do that myself. However I still like the idea of having an automatic process than scans the commit logs of stable and dev (see Robin's keyword suggestion). Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Closing Jira Bugs
Hi, what has to be done to close a Jira bug after the fix has been successfully merged? I've just checked some of the latest commits in dev with Task-numbers and all of the jira tasks are still in unresolved state. Would it make sense to automatically close JIRA bugs when a commit message contains a reference to it? Nils ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
On 01/30/2013 07:01 PM, Nils Jeisecke wrote: Hi, what has to be done to close a Jira bug after the fix has been successfully merged? I've just checked some of the latest commits in dev with Task-numbers and all of the jira tasks are still in unresolved state. leave a comment in the task asking the Reporter to verify if it's actually fixed and asking the Assignee to close it ? Would it make sense to automatically close JIRA bugs when a commit message contains a reference to it? How many changes do you need to close a jira task ? one, two, more, who knows ? I think it's not that easy to automate this. Nils Cheers, -- Sergio Ahumada s...@sansano.inf.utfsm.cl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
On quarta-feira, 30 de janeiro de 2013 19.05.55, Sergio Ahumada wrote: what has to be done to close a Jira bug after the fix has been successfully merged? I've just checked some of the latest commits in dev with Task-numbers and all of the jira tasks are still in unresolved state. leave a comment in the task asking the Reporter to verify if it's actually fixed and asking the Assignee to close it ? Someone has to go to JIRA and click the Fixed or Fixed and Verified buttons in the workflow, after the fix has landed. I do that when I get a Gerrit email for a change of mine that has successfully integrated and I recognise as a bugfix. If I forget to do it, I will eventually get to it when I do my periodic JIRA clean up. Those tasks are easy to spot because they are In Progress. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada s...@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). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
Op 30-1-2013 19:34, Robin Burchell schreef: On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada s...@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. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
Op 30-1-2013 19:34, Robin Burchell schreef: On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada s...@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? Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
Op 30-1-2013 21:19, Shaw Andy schreef: 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? Andy That can always happen, even after releasing. I don't see the issue with that. The bug would be re-opened, and the next patch that gets integrated with the right magical text in the commit message adds another comment again and may again change the status. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
On quarta-feira, 30 de janeiro de 2013 20.19.02, Shaw Andy wrote: 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? Sure, it can only happen when it integrates to release, stable or dev. If the fix didn't actually fix the issue, the tooling will never know it. This needs a human to find out about the fact anyway, so this human can reopen the issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Closing Jira Bugs
On Wed, Jan 30, 2013 at 12:19 PM, Shaw Andy andy.s...@digia.com wrote: Op 30-1-2013 19:34, Robin Burchell schreef: On Wed, Jan 30, 2013 at 7:05 PM, Sergio Ahumada s...@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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
