automation wrongly moving bugs to MODIFIED
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatically move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1282397 Best, -- Didi
--n/aVsWSeQ4JHkrmm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11/17 10:44, Yedidyah Bar David wrote:
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatically move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide.
The issue here is that there's no way for the hooks to know that you will be pushing more patches, so when it saw that there were no more open patches it moved the bug to MODIFIED. Is there any reason why you did not open the pat= ches first?
=20 [1] https://bugzilla.redhat.com/show_bug.cgi?id=3D1282397 =20 Best, --=20 Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --n/aVsWSeQ4JHkrmm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWSumvAAoJEEBxx+HSYmnD/GgIAJV3GWRrFEJ6q3gFwX+psJkw IR+BtpvHiTcKFe84cy4jW2WiL6/6uhCOfxd2CLh5j2ybb32NqI7M8WRSRUGjzCx2 5UGeydyFMOKtL3+WWdvXqXa2CNFmwOaHActZktZXYH4rvW9xSQFn+InWRCOgbkyW MuMvanjYzOcxseQ1+e3JjVkHOf0rk8gJJH+yliGPpraXl43ONsOOsr7ruvusfFot aPtWpe/5kKnzyLOOULJwXfn17ThhI2WcWavxgDjXuO8O3tOBKUEkzSGfyXof74uO +DGwFvN93weX9LWllPHfXIWOzj90rkWXV2RGNUyWlVeXEn2SQ3IqU95I5KganeQ= =HT/y -----END PGP SIGNATURE----- --n/aVsWSeQ4JHkrmm--
On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro@redhat.com> wrote:
On 11/17 10:44, Yedidyah Bar David wrote:
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatically move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide.
The issue here is that there's no way for the hooks to know that you will be pushing more patches, so when it saw that there were no more open patches it moved the bug to MODIFIED. Is there any reason why you did not open the patches first?
There are two different issues here: 1. If merging to master branch, and bug is 3.6, bug should not be moved to modified at all. 2. If merging to 3.6 branch, and bug is 3.6, we might or might not want to move to modified. Not always people push all patches at once - sometimes they prefer to have some preparation patch merged (perhaps after a long review process, during which the patch is changed quite a lot), then continue with more patches. This wasn't current case, although I still think we might want to open it to discussion. -- Didi
On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On 11/17 10:44, Yedidyah Bar David wrote:
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatically move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide.
The issue here is that there's no way for the hooks to know that you will be pushing more patches, so when it saw that there were no more open
moved the bug to MODIFIED. Is there any reason why you did not open the
On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro@redhat.com> wrote: patches it patches
first?
There are two different issues here:
1. If merging to master branch, and bug is 3.6, bug should not be moved to modified at all.
imo, the gerrit hook should give -1 on this. either don't put bug-url at all, or put 4.0 bug-url.
2. If merging to 3.6 branch, and bug is 3.6, we might or might not want to move to modified. Not always people push all patches at once - sometimes they prefer to have some preparation patch merged (perhaps after a long review process, during which the patch is changed quite a lot), then continue with more patches. This wasn't current case, although I still think we might want to open it to discussion.
i replied on this on the previous reply
-- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Eyal Edri Supervisor, RHEV CI EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri@redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro@redhat.com> wrote:
On 11/17 10:44, Yedidyah Bar David wrote:
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatically move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide.
The issue here is that there's no way for the hooks to know that you will be pushing more patches, so when it saw that there were no more open patches it moved the bug to MODIFIED. Is there any reason why you did not open the patches first?
There are two different issues here:
1. If merging to master branch, and bug is 3.6, bug should not be moved to modified at all.
imo, the gerrit hook should give -1 on this. either don't put bug-url at all, or put 4.0 bug-url.
Not sure about this. I agree it makes some sense. It definitely don't need to move to modified :-) Since we decided to not always clone bugs, and since we require merging to master before merging to stable branch, I think it does make sense to include the bug-url even in the master patch. obviously, Related-To is also good enough, even though a bit misleading - I usually write Related-To when the patch is not directly part of a fix for a bug but only related to it. -- Didi
On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri@redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro@redhat.com> wrote:
On 11/17 10:44, Yedidyah Bar David wrote:
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), =
bug
was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatica= lly move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide.
The issue here is that there's no way for the hooks to know that you will be pushing more patches, so when it saw that there were no more open patches it moved the bug to MODIFIED. Is there any reason why you did not open =
--Zi0sgQQBxRFxMTsj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 11/17 11:06, Yedidyah Bar David wrote: the
patches first?
There are two different issues here:
1. If merging to master branch, and bug is 3.6, bug should not be moved to modified at all.
imo, the gerrit hook should give -1 on this. either don't put bug-url at all, or put 4.0 bug-url. =20 Not sure about this. I agree it makes some sense. It definitely don't nee= d to move to modified :-) =20 Since we decided to not always clone bugs, and since we require merging to master before merging to stable branch, I think it does make sense to inc= lude the bug-url even in the master patch. obviously, Related-To is also good = enough, even though a bit misleading - I usually write Related-To when the patch = is not directly part of a fix for a bug but only related to it.
We used the related-to in the past, but iirc it was dropped as not everyone used it and people that did, used it for different things. I still think that opening all the patches before merging any of them is a = good solution.
--=20 Didi
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --Zi0sgQQBxRFxMTsj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWSu76AAoJEEBxx+HSYmnDyiUH/2+tHAOvn1ICB6DMnvm2lqXw vq33eHwgJ+CcFutnh9q0YVo8heSPM+qdtoaoNmyRrR/QIL4vz1JyZ3m/4PEJBbC4 +LvsTepZAFSg0tBSnBXsATR7SbxG2TB+IoroR3YFktN4NHQOZNP+/KFfRpp/NE51 VA8XE0WAWde1HiV8vfKYqv+s6nB1F9vxmEuKvEiU6ki925ghKiOdJBryomVXjf9H EDMfPz58SjZTvxEt7bSJsQKrfK2ztj9gMs5tDaKCJ946cllTQWyIyYPgY0vUJMBr 7eAhpjEfCx94ZKP/x2eSZ5RbITVgh2rwnjL98Tb1leKc65HppHq+f0+oP1D1jjU= =wLH3 -----END PGP SIGNATURE----- --Zi0sgQQBxRFxMTsj--
On Tue, Nov 17, 2015 at 11:10 AM, David Caro <dcaro@redhat.com> wrote:
On 11/17 11:06, Yedidyah Bar David wrote:
On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri@redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro@redhat.com> wrote:
On 11/17 10:44, Yedidyah Bar David wrote:
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatically move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide.
The issue here is that there's no way for the hooks to know that you will be pushing more patches, so when it saw that there were no more open patches it moved the bug to MODIFIED. Is there any reason why you did not open the patches first?
There are two different issues here:
1. If merging to master branch, and bug is 3.6, bug should not be moved to modified at all.
imo, the gerrit hook should give -1 on this. either don't put bug-url at all, or put 4.0 bug-url.
Not sure about this. I agree it makes some sense. It definitely don't need to move to modified :-)
Since we decided to not always clone bugs, and since we require merging to master before merging to stable branch, I think it does make sense to include the bug-url even in the master patch. obviously, Related-To is also good enough, even though a bit misleading - I usually write Related-To when the patch is not directly part of a fix for a bug but only related to it.
We used the related-to in the past, but iirc it was dropped as not everyone used it and people that did, used it for different things.
I still think that opening all the patches before merging any of them is a good solution.
Perhaps, if everyone is well aware of this. I still think there is no good reason to take this risk. I think saying "This bug is fixed" should always be left to a human. We have bots (or at least people doing this in bulk) for moving bugs from modified to QA. Moving to POST to MODIFIED is the only step left for a human to decide. IMO it should left so. -- Didi
indeed. we need to decide here what automation we want (each flow has its cons & pros) moving bugs from POST->MODIFIED - pros - bugs are not forgotten on POST and waiting for manual action, leaving possibility of not moving to ON_QA on a release even though they are fixed. - cons - bot can't know if bug is solved completely and more patches are coming. solution: - use bug-url ONLY in the main patch that when its merged then bug will move to MODIFIED, all other patches should use related-to: (we can ensure bug won't change status for related to patches) moving MODIFIED->POST - i think in any case we should stop doing this, and its the maintainer responsibility to move it back to POST if he didn't add all patches. - adding a comment will help the bug owner know about this issue. e. On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro@redhat.com> wrote:
On 11/17 10:44, Yedidyah Bar David wrote:
See e.g. [1]. Patch was merged to master only (not to 3.6 branch), bug was moved to modified. When I later pushed the patch to 3.6, it correctly moved it back to POST. Not sure we should even automatically move to modified if merged to 3.6, because there might be other changes needed for that bug - it might be best to let the owner to decide.
The issue here is that there's no way for the hooks to know that you will be pushing more patches, so when it saw that there were no more open patches it moved the bug to MODIFIED. Is there any reason why you did not open the patches first?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1282397
Best, -- Didi _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- David Caro
Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Eyal Edri Supervisor, RHEV CI EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
On Tue, Nov 17, 2015 at 10:54 AM, Eyal Edri <eedri@redhat.com> wrote:
indeed. we need to decide here what automation we want (each flow has its cons & pros)
moving bugs from POST->MODIFIED - pros - bugs are not forgotten on POST and waiting for manual action, leaving possibility of not moving to ON_QA on a release even though they are fixed.
I think it's still a bit risky and should be left for a human. At least as long as we do not do TDD.
- cons - bot can't know if bug is solved completely and more patches are coming.
solution: - use bug-url ONLY in the main patch that when its merged then bug will move to MODIFIED, all other patches should use related-to: (we can ensure bug won't change status for related to patches)
I can live with this, but as I wrote in another mail in this thread, I think that's a bit overloading the meaning of Related-To.
moving MODIFIED->POST - i think in any case we should stop doing this, and its the maintainer responsibility to move it back to POST if he didn't add all patches.
Really? Do you see any risk in moving to POST? -- Didi
On Tue, Nov 17, 2015 at 11:11 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:54 AM, Eyal Edri <eedri@redhat.com> wrote:
indeed. we need to decide here what automation we want (each flow has its cons & pros)
moving bugs from POST->MODIFIED - pros - bugs are not forgotten on POST and waiting for manual action, leaving possibility of not moving to ON_QA on a release even though they are fixed.
I think it's still a bit risky and should be left for a human. At least as long as we do not do TDD.
- cons - bot can't know if bug is solved completely and more patches are coming.
solution: - use bug-url ONLY in the main patch that when its merged
then
bug will move to MODIFIED, all other patches should use related-to: (we can ensure bug won't change status for related to patches)
I can live with this, but as I wrote in another mail in this thread, I think that's a bit overloading the meaning of Related-To.
moving MODIFIED->POST - i think in any case we should stop doing this, and its the maintainer responsibility to move it back to POST if he didn't add all patches.
Really? Do you see any risk in moving to POST?
yes. we talked in the past about bots moving statues back, and it should be left for human - i don't see a reason why this should be different. but we can bring it up for discussion, a change in hooks affects everyone and not to be decided on a mail thread
-- Didi
-- Eyal Edri Supervisor, RHEV CI EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 irc: eedri (on #tlv #rhev-dev #rhev-integ)
participants (3)
-
David Caro -
Eyal Edri -
Yedidyah Bar David