| 2012-06-26 16:28:41 |
Daniel Berrange |
bug |
|
|
added bug |
| 2012-06-26 16:52:39 |
Monty Taylor |
openstack-ci: importance |
Undecided |
Medium |
|
| 2012-06-26 16:52:42 |
Monty Taylor |
openstack-ci: status |
New |
Triaged |
|
| 2012-06-26 16:52:47 |
Monty Taylor |
openstack-ci: milestone |
|
folsom |
|
| 2012-07-12 16:37:28 |
Thierry Carrez |
tags |
|
update-bug |
|
| 2012-09-24 12:54:33 |
Monty Taylor |
openstack-ci: milestone |
folsom |
grizzly |
|
| 2012-09-24 12:54:57 |
Monty Taylor |
openstack-ci: assignee |
|
Thierry Carrez (ttx) |
|
| 2012-10-12 09:20:24 |
Thierry Carrez |
tags |
update-bug |
updatebug |
|
| 2012-11-14 14:08:11 |
Thierry Carrez |
openstack-ci: assignee |
Thierry Carrez (ttx) |
|
|
| 2013-04-23 20:50:26 |
Clark Boylan |
openstack-ci: milestone |
grizzly |
havana |
|
| 2013-04-23 20:55:18 |
Clark Boylan |
tags |
updatebug |
low-hanging-fruit updatebug |
|
| 2013-06-23 00:38:31 |
Anas Alkhatib |
bug |
|
|
added subscriber anas.alkhatib |
| 2013-06-25 17:44:19 |
Anthony Dodd |
openstack-ci: assignee |
|
Anthony Dodd (thedodd) |
|
| 2013-06-25 17:44:25 |
Anthony Dodd |
openstack-ci: status |
Triaged |
In Progress |
|
| 2013-06-25 17:50:56 |
Anthony Dodd |
description |
The current script that integrates GIT commits merged from Gerrit, with the bug tracker has sub-optimal behaviour when deal with fixes that span across multiple commits. When preparing a patch series is it natural to note the bug number in all of the patches in the series which are directly relevant. When updating the bug status to 'Fix committed', however, the Gerrit hooks only consider each patch in isolation. So if 1 single patch out of a series is merged, but the others are not, the bug will get prematurely marked as 'Fix committed'.
The only current way to deal with this is to refrain from mentioning the bug number in all but the very last commit in the patch sequence. This is undesirable though, since the bug number is useful data for the GIT history, and we do want all patches related to the bug to be tracked as a whole.
The current Gerrit bug hook:
https://github.com/openstack/openstack-ci-puppet/blob/master/modules/gerrit/files/scripts/update_bug.py
matches on a regex
bug_regexp = r'([Bb]ug|[Ll][Pp])[\s#:]*(\d+)'
So anything like
Bug #NNNN
will cause the bug to be closed once commited.
I would suggest expanding the syntax to allow an (optional) qualifier to be prefixed eg
Related bug #NNNN
Resolves bug #NNNN
Any bug qualifier would cause the commit to be associated with the bug, but only the 'resolves' qualifier would cause the bug to be marked as 'Fix commited'. For compat with existing practice & easing of the "simple" non-patch series case, the lack of any qualifier would be treated as meaning 'Resolves'. So only people creating patch series, would need to use 'Resolves' vs 'Related' distinction
A completely different idea, would be to try and identify complete patch series in gerrit, and automatically "do the right thing"
wit the bug tracker only marking it as resolved once the entire series is committed. I'm not sure how practical that is though, given Gerrits' limited understanding of patch series. eg could it detect this example:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1003373,n,z
where all 5 patches were pushed to gerrit at once ? |
The current script that integrates GIT commits merged from Gerrit, with the bug tracker has sub-optimal behaviour when dealing with fixes that span across multiple commits. When preparing a patch series is it natural to note the bug number in all of the patches in the series which are directly relevant. When updating the bug status to 'Fix committed', however, the Gerrit hooks only consider each patch in isolation. So if 1 single patch out of a series is merged, but the others are not, the bug will get prematurely marked as 'Fix committed'.
The only current way to deal with this is to refrain from mentioning the bug number in all but the very last commit in the patch sequence. This is undesirable though, since the bug number is useful data for the GIT history, and we do want all patches related to the bug to be tracked as a whole.
The current Gerrit bug hook:
https://github.com/openstack/openstack-ci-puppet/blob/master/modules/gerrit/files/scripts/update_bug.py
matches on a regex
bug_regexp = r'([Bb]ug|[Ll][Pp])[\s#:]*(\d+)'
So anything like
Bug #NNNN
will cause the bug to be closed once commited.
I would suggest expanding the syntax to allow an (optional) qualifier to be prefixed eg
Related bug #NNNN
Resolves bug #NNNN
Any bug qualifier would cause the commit to be associated with the bug, but only the 'resolves' qualifier would cause the bug to be marked as 'Fix commited'. For compat with existing practice & easing of the "simple" non-patch series case, the lack of any qualifier would be treated as meaning 'Resolves'. So only people creating patch series, would need to use 'Resolves' vs 'Related' distinction
A completely different idea, would be to try and identify complete patch series in gerrit, and automatically "do the right thing"
wit the bug tracker only marking it as resolved once the entire series is committed. I'm not sure how practical that is though, given Gerrits' limited understanding of patch series. eg could it detect this example:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1003373,n,z
where all 5 patches were pushed to gerrit at once ? |
|
| 2013-06-25 19:24:52 |
Anthony Dodd |
description |
The current script that integrates GIT commits merged from Gerrit, with the bug tracker has sub-optimal behaviour when dealing with fixes that span across multiple commits. When preparing a patch series is it natural to note the bug number in all of the patches in the series which are directly relevant. When updating the bug status to 'Fix committed', however, the Gerrit hooks only consider each patch in isolation. So if 1 single patch out of a series is merged, but the others are not, the bug will get prematurely marked as 'Fix committed'.
The only current way to deal with this is to refrain from mentioning the bug number in all but the very last commit in the patch sequence. This is undesirable though, since the bug number is useful data for the GIT history, and we do want all patches related to the bug to be tracked as a whole.
The current Gerrit bug hook:
https://github.com/openstack/openstack-ci-puppet/blob/master/modules/gerrit/files/scripts/update_bug.py
matches on a regex
bug_regexp = r'([Bb]ug|[Ll][Pp])[\s#:]*(\d+)'
So anything like
Bug #NNNN
will cause the bug to be closed once commited.
I would suggest expanding the syntax to allow an (optional) qualifier to be prefixed eg
Related bug #NNNN
Resolves bug #NNNN
Any bug qualifier would cause the commit to be associated with the bug, but only the 'resolves' qualifier would cause the bug to be marked as 'Fix commited'. For compat with existing practice & easing of the "simple" non-patch series case, the lack of any qualifier would be treated as meaning 'Resolves'. So only people creating patch series, would need to use 'Resolves' vs 'Related' distinction
A completely different idea, would be to try and identify complete patch series in gerrit, and automatically "do the right thing"
wit the bug tracker only marking it as resolved once the entire series is committed. I'm not sure how practical that is though, given Gerrits' limited understanding of patch series. eg could it detect this example:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1003373,n,z
where all 5 patches were pushed to gerrit at once ? |
The current script that integrates GIT commits merged from Gerrit, with the bug tracker has sub-optimal behaviour when dealing with fixes that span across multiple commits. When preparing a patch series it is natural to note the bug number in all of the patches in the series which are directly relevant. When updating the bug status to 'Fix committed', however, the Gerrit hooks only consider each patch in isolation. So if 1 single patch out of a series is merged, but the others are not, the bug will get prematurely marked as 'Fix committed'.
The only current way to deal with this is to refrain from mentioning the bug number in all but the very last commit in the patch sequence. This is undesirable though, since the bug number is useful data for the GIT history, and we do want all patches related to the bug to be tracked as a whole.
The current Gerrit bug hook:
https://github.com/openstack/openstack-ci-puppet/blob/master/modules/gerrit/files/scripts/update_bug.py
matches on a regex
bug_regexp = r'([Bb]ug|[Ll][Pp])[\s#:]*(\d+)'
So anything like
Bug #NNNN
will cause the bug to be closed once commited.
I would suggest expanding the syntax to allow an (optional) qualifier to be prefixed eg
Related bug #NNNN
Resolves bug #NNNN
Any bug qualifier would cause the commit to be associated with the bug, but only the 'resolves' qualifier would cause the bug to be marked as 'Fix commited'. For compat with existing practice & easing of the "simple" non-patch series case, the lack of any qualifier would be treated as meaning 'Resolves'. So only people creating patch series, would need to use 'Resolves' vs 'Related' distinction
A completely different idea, would be to try and identify complete patch series in gerrit, and automatically "do the right thing"
wit the bug tracker only marking it as resolved once the entire series is committed. I'm not sure how practical that is though, given Gerrits' limited understanding of patch series. eg could it detect this example:
https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1003373,n,z
where all 5 patches were pushed to gerrit at once ? |
|
| 2013-07-09 14:00:04 |
Burt Holzman |
bug |
|
|
added subscriber Burt Holzman |
| 2013-07-29 18:08:08 |
OpenStack Infra |
openstack-ci: status |
In Progress |
Fix Committed |
|
| 2014-05-29 20:28:21 |
Khai Do |
openstack-ci: status |
Fix Committed |
Fix Released |
|
