10:44 a.m.
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
10:47 a.m.
--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(a)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(a)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--
10:53 a.m.
On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro(a)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
10:56 a.m.
On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro(a)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.
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(a)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)
11:06 a.m.
On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri(a)redhat.com> wrote:
On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
>
> On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro(a)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
11:10 a.m.
--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:
On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri(a)redhat.com>
wrote:
>
>
> On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi(a)redhat.com>
> wrote:
>>
>> On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro(a)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 =
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(a)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--
11:14 a.m.
On Tue, Nov 17, 2015 at 11:10 AM, David Caro <dcaro(a)redhat.com> wrote:
On 11/17 11:06, Yedidyah Bar David wrote:
> On Tue, Nov 17, 2015 at 10:56 AM, Eyal Edri <eedri(a)redhat.com> wrote:
> >
> >
> > On Tue, Nov 17, 2015 at 10:53 AM, Yedidyah Bar David <didi(a)redhat.com>
> > wrote:
> >>
> >> On Tue, Nov 17, 2015 at 10:47 AM, David Caro <dcaro(a)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
10:54 a.m.
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(a)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(a)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(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
_______________________________________________
Infra mailing list
Infra(a)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)
11:11 a.m.
On Tue, Nov 17, 2015 at 10:54 AM, Eyal Edri <eedri(a)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
11:15 a.m.
On Tue, Nov 17, 2015 at 11:11 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
On Tue, Nov 17, 2015 at 10:54 AM, Eyal Edri <eedri(a)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)
3293
days inactive
3293
days old
9 comments
3 participants
participants (3)
-
David Caro -
Eyal Edri -
Yedidyah Bar David