10:10 a.m.
Hi all,
We currently have a bot that automatically moves bugs from POST to MODIFIED
if all linked patches on gerrit are merged.
It happened to me personally several times that this was a wrong thing to do,
either because a new patch was still needed but not pushed yet, or because
an existing patch should have been back-ported to another branch and wasn't
yet. Since I usually pay more attention to my bug in POST, I sometimes missed
this and handled the missing patches (backports, usually) later than I could
if left on POST.
I have a feeling I am not the only one. So I suggest to stop doing this.
I can think of several alternatives:
1. Do nothing. I think that's reasonable - I think most people pay more
attention to POST bugs anyway.
2. Set needinfo on bug owner.
3. Send some alert email to relevant people (bug owner, existing patches owners,
perhaps others - e.g. reviewers of existing patches, perhaps those
that actually reviewed, etc.). Need to think how to make it not too
annoying for others but
still effective also if owner is on long PTO or something like that. New flag
doesn't have to be very specific - can be called something like 'attention
needed' or something like that.
4. Add a new flag for that and set it. This will allow easier
filtering/reporting.
What do you think?
--
Didi
12:06 p.m.
I also got this, especially when bugs should be back-ported
+1 for option #1
On Wed, Aug 17, 2016 at 10:10 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
Hi all,
We currently have a bot that automatically moves bugs from POST to MODIFIED
if all linked patches on gerrit are merged.
It happened to me personally several times that this was a wrong thing to
do,
either because a new patch was still needed but not pushed yet, or because
an existing patch should have been back-ported to another branch and wasn't
yet. Since I usually pay more attention to my bug in POST, I sometimes
missed
this and handled the missing patches (backports, usually) later than I
could
if left on POST.
I have a feeling I am not the only one. So I suggest to stop doing this.
I can think of several alternatives:
1. Do nothing. I think that's reasonable - I think most people pay more
attention to POST bugs anyway.
2. Set needinfo on bug owner.
3. Send some alert email to relevant people (bug owner, existing patches
owners,
perhaps others - e.g. reviewers of existing patches, perhaps those
that actually reviewed, etc.). Need to think how to make it not too
annoying for others but
still effective also if owner is on long PTO or something like that. New
flag
doesn't have to be very specific - can be called something like 'attention
needed' or something like that.
4. Add a new flag for that and set it. This will allow easier
filtering/reporting.
What do you think?
--
Didi
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
12:08 p.m.
בתאריך 17 באוג׳ 2016 12:06 אחה״צ, "Eli Mesika" <emesika(a)redhat.com> כתב:
I also got this, especially when bugs should be back-ported
+1 for option #1
On Wed, Aug 17, 2016 at 10:10 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
>
> Hi all,
>
> We currently have a bot that automatically moves bugs from POST to
MODIFIED
> if all linked patches on gerrit are merged.
>
> It happened to me personally several times that this was a wrong thing
to do,
> either because a new patch was still needed but not pushed yet,
or
because
> an existing patch should have been back-ported to another branch
and
wasn't
> yet. Since I usually pay more attention to my bug in POST, I
sometimes
missed
> this and handled the missing patches (backports, usually) later
than I
could
> if left on POST.
>
> I have a feeling I am not the only one. So I suggest to stop doing this.
>
> I can think of several alternatives:
>
> 1. Do nothing. I think that's reasonable - I think most people pay more
> attention to POST bugs anyway.
+1
>
> 2. Set needinfo on bug owner.
>
> 3. Send some alert email to relevant people (bug owner, existing patches
owners,
> perhaps others - e.g. reviewers of existing patches, perhaps
those
> that actually reviewed, etc.). Need to think how to make it not too
> annoying for others but
> still effective also if owner is on long PTO or something like that. New
flag
> doesn't have to be very specific - can be called something
like
'attention
> needed' or something like that.
>
> 4. Add a new flag for that and set it. This will allow easier
> filtering/reporting.
>
> What do you think?
> --
> Didi
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
1:45 p.m.
I still thinks its a very valuable hook and we are aware of the fact it has
bugs, especially with patches on master branch and 4.0.
Shlomi from the infra team is working on a solution for it as we speak and
we hope to have a solution in the next few days, however it's not trival
to test and requires setting up a staging env and improve loga for the
hooks system.
On Aug 17, 2016 12:06 PM, "Eli Mesika" <emesika(a)redhat.com> wrote:
I also got this, especially when bugs should be back-ported
+1 for option #1
On Wed, Aug 17, 2016 at 10:10 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
> Hi all,
>
> We currently have a bot that automatically moves bugs from POST to
> MODIFIED
> if all linked patches on gerrit are merged.
>
> It happened to me personally several times that this was a wrong thing to
> do,
> either because a new patch was still needed but not pushed yet, or because
> an existing patch should have been back-ported to another branch and
> wasn't
> yet. Since I usually pay more attention to my bug in POST, I sometimes
> missed
> this and handled the missing patches (backports, usually) later than I
> could
> if left on POST.
>
> I have a feeling I am not the only one. So I suggest to stop doing this.
>
> I can think of several alternatives:
>
> 1. Do nothing. I think that's reasonable - I think most people pay more
> attention to POST bugs anyway.
>
> 2. Set needinfo on bug owner.
>
> 3. Send some alert email to relevant people (bug owner, existing patches
> owners,
> perhaps others - e.g. reviewers of existing patches, perhaps those
> that actually reviewed, etc.). Need to think how to make it not too
> annoying for others but
> still effective also if owner is on long PTO or something like that. New
> flag
> doesn't have to be very specific - can be called something like 'attention
> needed' or something like that.
>
> 4. Add a new flag for that and set it. This will allow easier
> filtering/reporting.
>
> What do you think?
> --
> Didi
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2:25 p.m.
On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com> wrote:
I still thinks its a very valuable hook and we are aware of the fact
it has
bugs, especially with patches on master branch and 4.0.
Shlomi from the infra team is working on a solution for it as we speak and
we hope to have a solution in the next few days, however it's not trival to
test and requires setting up a staging env and improve loga for the hooks
system.
How do you plan to solve this?
Only the owner of the bug knows if the all the required patches are merged
and backported to the correct repositories.
On Aug 17, 2016 12:06 PM, "Eli Mesika"
<emesika(a)redhat.com> wrote:
>
> I also got this, especially when bugs should be back-ported
> +1 for option #1
>
> On Wed, Aug 17, 2016 at 10:10 AM, Yedidyah Bar David <didi(a)redhat.com>
> wrote:
>>
>> Hi all,
>>
>> We currently have a bot that automatically moves bugs from POST to
>> MODIFIED
>> if all linked patches on gerrit are merged.
>>
>> It happened to me personally several times that this was a wrong thing to
>> do,
>> either because a new patch was still needed but not pushed yet, or
>> because
>> an existing patch should have been back-ported to another branch and
>> wasn't
>> yet. Since I usually pay more attention to my bug in POST, I sometimes
>> missed
>> this and handled the missing patches (backports, usually) later than I
>> could
>> if left on POST.
>>
>> I have a feeling I am not the only one. So I suggest to stop doing this.
>>
>> I can think of several alternatives:
>>
>> 1. Do nothing. I think that's reasonable - I think most people pay more
>> attention to POST bugs anyway.
>>
>> 2. Set needinfo on bug owner.
>>
>> 3. Send some alert email to relevant people (bug owner, existing patches
>> owners,
>> perhaps others - e.g. reviewers of existing patches, perhaps those
>> that actually reviewed, etc.). Need to think how to make it not too
>> annoying for others but
>> still effective also if owner is on long PTO or something like that. New
>> flag
>> doesn't have to be very specific - can be called something like
>> 'attention
>> needed' or something like that.
>>
>> 4. Add a new flag for that and set it. This will allow easier
>> filtering/reporting.
>>
>> What do you think?
>> --
>> Didi
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2:47 p.m.
On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com>
wrote:
> I still thinks its a very valuable hook and we are aware of the fact it
has
> bugs, especially with patches on master branch and 4.0.
>
> Shlomi from the infra team is working on a solution for it as we speak
and
> we hope to have a solution in the next few days, however it's not
trival to
> test and requires setting up a staging env and improve loga for the hooks
> system.
How do you plan to solve this?
Only the owner of the bug knows if the all the required patches are merged
The authors should use Bug-Url on the main bug and related-to: on other
patches that are related.
and backported to the correct repositories.
This is done with logic according to the bug target milestone.
for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug targeted
to ovirt-4.0.2.
The hook should check if branch 4.0.2 exists or not, if it exists then the
bug should NOT move to MODIFIED,
since it needs still backporting to ovirt-engine-4.0.2 branch.
> On Aug 17, 2016 12:06 PM, "Eli Mesika" <emesika(a)redhat.com> wrote:
>>
>> I also got this, especially when bugs should be back-ported
>> +1 for option #1
>>
>> On Wed, Aug 17, 2016 at 10:10 AM, Yedidyah Bar David <didi(a)redhat.com>
>> wrote:
>>>
>>> Hi all,
>>>
>>> We currently have a bot that automatically moves bugs from POST to
>>> MODIFIED
>>> if all linked patches on gerrit are merged.
>>>
>>> It happened to me personally several times that this was a wrong thing
to
>>> do,
>>> either because a new patch was still needed but not pushed yet, or
>>> because
>>> an existing patch should have been back-ported to another branch and
>>> wasn't
>>> yet. Since I usually pay more attention to my bug in POST, I sometimes
>>> missed
>>> this and handled the missing patches (backports, usually) later than I
>>> could
>>> if left on POST.
>>>
>>> I have a feeling I am not the only one. So I suggest to stop doing
this.
>>>
>>> I can think of several alternatives:
>>>
>>> 1. Do nothing. I think that's reasonable - I think most people pay more
>>> attention to POST bugs anyway.
>>>
>>> 2. Set needinfo on bug owner.
>>>
>>> 3. Send some alert email to relevant people (bug owner, existing
patches
>>> owners,
>>> perhaps others - e.g. reviewers of existing patches, perhaps those
>>> that actually reviewed, etc.). Need to think how to make it not too
>>> annoying for others but
>>> still effective also if owner is on long PTO or something like that.
New
>>> flag
>>> doesn't have to be very specific - can be called something like
>>> 'attention
>>> needed' or something like that.
>>>
>>> 4. Add a new flag for that and set it. This will allow easier
>>> filtering/reporting.
>>>
>>> What do you think?
>>> --
>>> Didi
>>> _______________________________________________
>>> Devel mailing list
>>> Devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
2:52 p.m.
--8i1HOXugmSQuWueLEopGDxqPBUDajpkQm
Content-Type: multipart/mixed; boundary="0l3UX7XhUGI78WFlaq7nHEGVAdiMuJlAm"
From: Sven Kieske <s.kieske(a)mittwald.de>
To: devel(a)ovirt.org
Message-ID: <c9191e61-516f-b6dc-5d8f-b88de771511c(a)mittwald.de>
X-Authenticated-mymxserver.com: Yes
Subject: Re: [ovirt-devel] Alternatives to automatically move bugs to MODIFIED
References: <CAHRwYXsjENpVj-wWiRFcd1h9FWSp4FWVYH0oEP72wT91v0qVbA(a)mail.gmail.com>
<CAMRbyyt=H2ycdvD6JkgNf8guRt+wz4xhrrAR0jViHxcrURN4+Q(a)mail.gmail.com>
In-Reply-To: <CAMRbyyt=H2ycdvD6JkgNf8guRt+wz4xhrrAR0jViHxcrURN4+Q(a)mail.gmail.com>
--0l3UX7XhUGI78WFlaq7nHEGVAdiMuJlAm
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
On 17/08/16 13:25, Nir Soffer wrote:
Only the owner of the bug knows if the all the required patches are
mer=
ged
and backported to the correct repositories.
Why not just set needinfo on bug assignee when all linked patches
are merged? this would ensure that missing patches get uploaded
asap and once this is done and all patches are merged you can clear
needinfo and move the bug to modified manually?
--=20
Mit freundlichen Gr=FC=DFen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
K=F6nigsberger Stra=DFe 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Gesch=E4ftsf=FChrer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhause=
n
Komplement=E4rin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynha=
usen
--0l3UX7XhUGI78WFlaq7nHEGVAdiMuJlAm--
--8i1HOXugmSQuWueLEopGDxqPBUDajpkQm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJXtFANAAoJEMby9TMDAbQRLsIP/RwTlK74FLs2v3HD/ABO7ehD
RwNnW/E2+J+PK7KkCy6eDoupXd/0Q+ae2vGd1JmapZmnc1rO9sFWjClor80mVpjt
Rtq9gOzxc/kqOwQt8sm0YQVNA4+crHY/ohEqBE0GChagllaySe4zfD0XdAL/aTEg
w6eCqdxqZixVpX7wL/vEv5SlhLU5lGFQcTEhd+l4aEUGVz+3E8FgDtH4/vU6h72u
Zbi9Fe72s/besTCS2NWuFwr5vwd8PtgIYja/de3tmnUtODevgUSEr3v0PuvPt0sL
00n1ewDpIq+X2JbRF1mdZ09O2FENmtEdk+9oHX8q04XdRX0O8mK+2tzqw+zy8+9d
OraLSgctWghbGdq65qVn3uy1vXbantPqjkjxajxdiBrPjzbGGqVtxy1cZK6lx09c
zq7rv8qKg93SlWikP1/ZCFCReu97t982FSMWmwBy/F6rNra6k/CsrrwQEvH5zJy0
aOe/MdviWBcZmxBXJjWXaRahjcx9sWXFmT4IXBJWG9L6HCQBRVqpPjgmXIcii1BA
FfKIDqJBK8PWHX4KRfgswIsJIY/2e+7a9a9VudaNVPTm3AB3Usw4CbWVoj+H6XU6
QyJnQw4FZZ6sTNFlcG/nQaa/omy1iT8NS6ABoRMjdHm0M+g7lqKyAUtYncC6zfbN
ErOqnJc/COm0XwD7H4IE
=OFEe
-----END PGP SIGNATURE-----
--8i1HOXugmSQuWueLEopGDxqPBUDajpkQm--
2:56 p.m.
On Wed, Aug 17, 2016 at 2:52 PM, Sven Kieske <s.kieske(a)mittwald.de> wrote:
On 17/08/16 13:25, Nir Soffer wrote:
> Only the owner of the bug knows if the all the required patches are
merged
> and backported to the correct repositories.
Why not just set needinfo on bug assignee when all linked patches
are merged? this would ensure that missing patches get uploaded
asap and once this is done and all patches are merged you can clear
needinfo and move the bug to modified manually?
You're optimistic that you'll get the info in time before a build.
If you want a certain bug to be included in a release then you have to make
sure that bug
is on MODIFIED before build time, waiting on human to do instead of bot has
its cons:
- the person can be on PTO / Leave and won't see the email - thus a bug
will miss a release
- people miss emails all the time, especially if you have multiple work
with bugzilla, I remember more than once
bugs left with NEEDINFO for quite a long time.
In the end, I think we should still make an effort to find the right logic
to do with bot,
keeping this task manual will cause more bugs to be left on POST from my
experience (we used to do it in the past)
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +495772 293100
F: +495772 293333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
6:12 p.m.
On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com> wrote:
On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>
> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com> wrote:
> > I still thinks its a very valuable hook and we are aware of the fact it
> > has
> > bugs, especially with patches on master branch and 4.0.
> >
> > Shlomi from the infra team is working on a solution for it as we speak
> > and
> > we hope to have a solution in the next few days, however it's not
> > trival to
> > test and requires setting up a staging env and improve loga for the
> > hooks
> > system.
>
> How do you plan to solve this?
>
> Only the owner of the bug knows if the all the required patches are merged
The authors should use Bug-Url on the main bug and related-to: on other
patches that are related.
This is not possible. Many times you need series of patches to fix a bug, and
you the number of patches may change during development. You start with one
patch, and later you find that you need another one, so all of them will have
a bug url.
Practically, you should expect that all patches in the series will
have a bug-url.
If the hook will change the bug incorrectly someone will have to fix this, and
it is very unlikely that a developer will go to clean after the hook.
> and backported to the correct repositories.
This is done with logic according to the bug target milestone.
for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug targeted to
ovirt-4.0.2.
The hook should check if branch 4.0.2 exists or not, if it exists then the
bug should NOT move to MODIFIED,
since it needs still backporting to ovirt-engine-4.0.2 branch.
This is too fragile. For example, maybe a 4.0.2 branch is created after
the patch was merged to 4.0 branch, and the patch will be missing, although
the bug is already set to modified.
Setting to modified should be done by the owner of the bug, after verifying
that the patches exists in correct branch.
I'm not suggesting to remove the hook, just disable the feature of making
a bug modified.
Nir
10:09 a.m.
On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com>
wrote:
>
>
> On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>>
>> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com> wrote:
>> > I still thinks its a very valuable hook and we are aware of the fact
it
>> > has
>> > bugs, especially with patches on master branch and 4.0.
>> >
>> > Shlomi from the infra team is working on a solution for it as we speak
>> > and
>> > we hope to have a solution in the next few days, however it's not
>> > trival to
>> > test and requires setting up a staging env and improve loga for the
>> > hooks
>> > system.
>>
>> How do you plan to solve this?
>>
>> Only the owner of the bug knows if the all the required patches are
merged
>
>
> The authors should use Bug-Url on the main bug and related-to: on other
> patches that are related.
This is not possible. Many times you need series of patches to fix a bug,
and
you the number of patches may change during development. You start with one
patch, and later you find that you need another one, so all of them will
have
a bug url.
Practically, you should expect that all patches in the series will
have a bug-url.
If the hook will change the bug incorrectly someone will have to fix this,
and
it is very unlikely that a developer will go to clean after the hook.
>> and backported to the correct repositories.
>
>
> This is done with logic according to the bug target milestone.
>
> for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug
targeted to
> ovirt-4.0.2.
> The hook should check if branch 4.0.2 exists or not, if it exists then
the
> bug should NOT move to MODIFIED,
> since it needs still backporting to ovirt-engine-4.0.2 branch.
This is too fragile. For example, maybe a 4.0.2 branch is created after
the patch was merged to 4.0 branch, and the patch will be missing, although
the bug is already set to modified.
Setting to modified should be done by the owner of the bug, after verifying
that the patches exists in correct branch.
I'm not suggesting to remove the hook, just disable the feature of making
a bug modified.
+1. On build day checking that bugs in modified not listed in Bug-Url on
the build branch due to missing backport is a painful experience.
Nir
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10:19 a.m.
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
On 18 Aug 2016, at 09:09, Sandro Bonazzola
<sbonazzo(a)redhat.com> =
wrote:
=20
=20
=20
On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com =
<mailto:nsoffer@redhat.com>> wrote:
On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com =
<mailto:eedri@redhat.com>> wrote:
>
>
> On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com =
<mailto:nsoffer@redhat.com>> wrote:
>>
>> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com =
<mailto:eedri@redhat.com>> wrote:
>> > I still thinks its a very valuable hook and we are
aware of the =
fact it
>> > has
>> > bugs, especially with patches on master branch and 4.0.
>> >
>> > Shlomi from the infra team is working on a solution for it as we =
speak
>> > and
>> > we hope to have a solution in the next few days, however it's =
not
>> > trival to
>> > test and requires setting up a staging env and improve loga for =
the
>> > hooks
>> > system.
>>
>> How do you plan to solve this?
>>
>> Only the owner of the bug knows if the all the required patches are =
merged
>
>
> The authors should use Bug-Url on the main bug and related-to: on =
other
> patches that are related.
=20
This is not possible. Many times you need series of patches to fix a =
bug, and
you the number of patches may change during development. You start =
with one
patch, and later you find that you need another one, so all of them =
will have
a bug url.
=20
Practically, you should expect that all patches in the series will
have a bug-url.
If the hook will change the bug incorrectly someone will have to fix =
this, and
it is very unlikely that a developer will go to clean after the
hook.
=20
>> and backported to the correct repositories.
>
>
> This is done with logic according to the bug target milestone.
>
> for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug =
targeted to
> ovirt-4.0.2.
> The hook should check if branch 4.0.2 exists or not, if it exists =
then the
> bug should NOT move to MODIFIED,
> since it needs still backporting to ovirt-engine-4.0.2 branch.
=20
This is too fragile. For example, maybe a 4.0.2 branch is created =
after
the patch was merged to 4.0 branch, and the patch will be missing, =
although
the bug is already set to modified.
=20
Setting to modified should be done by the owner of the bug, after =
verifying
that the patches exists in correct branch.
=20
I'm not suggesting to remove the hook, just disable the feature of =
making
a bug modified.
=20
+1. On build day checking that bugs in modified not listed in Bug-Url =
on the
build branch due to missing backport is a painful experience.
it is a tradeoff. It was mentioned before that the other way around we =
would be left with too many POSTed bugs which are actually already =
merged. The maintainer is typically not the assignee so if you e.g. =
merge the last patch on Thursday afternoon it takes some time to gets =
attention, in the meantime there is a build which won=E2=80=99t consider =
that bug.
=20
=20
=20
Nir
=20
=20
=20
--=20
Sandro Bonazzola
Better technology. Faster innovation. Powered by community =
collaboration.
See how it works at redhat.com <http://redhat.com/>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 18 Aug 2016, at 09:09, Sandro Bonazzola <<a =
href=3D"mailto:sbonazzo@redhat.com"
class=3D"">sbonazzo(a)redhat.com</a>&gt;=
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><div =
dir=3D"ltr" class=3D""><br class=3D""><div
class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Wed, Aug 17, 2016 at
5:12 PM, =
Nir Soffer <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:nsoffer@redhat.com" target=3D"_blank" =
class=3D"">nsoffer(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=3D"">On =
Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <<a =
href=3D"mailto:eedri@redhat.com"
class=3D"">eedri(a)redhat.com</a>&gt; =
wrote:<br class=3D"">
><br class=3D"">
><br class=3D"">
> On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <<a =
href=3D"mailto:nsoffer@redhat.com"
class=3D"">nsoffer(a)redhat.com</a>&gt; =
wrote:<br class=3D"">
>><br class=3D"">
</span><span class=3D"">>> On Wed, Aug 17, 2016 at
1:45 PM, Eyal =
Edri <<a href=3D"mailto:eedri@redhat.com" =
class=3D"">eedri(a)redhat.com</a>&gt; wrote:<br
class=3D"">
>> > I still thinks its a very valuable hook and we are aware =
of the fact it<br class=3D"">
>> > has<br class=3D"">
>> > bugs, especially with patches on master branch and =
4.0.<br class=3D"">
>> ><br class=3D"">
>> > Shlomi from the infra team is working on a solution for it =
as we speak<br class=3D"">
>> > and<br class=3D"">
>> > we hope to have a solution in the next few days, =
however it's not<br class=3D"">
>> > trival to<br class=3D"">
>> > test and requires setting up a staging env and improve =
loga for the<br class=3D"">
>> > hooks<br class=3D"">
>> > system.<br class=3D"">
>><br class=3D"">
>> How do you plan to solve this?<br class=3D"">
>><br class=3D"">
</span><span class=3D"">>> Only the owner of the bug
knows if the =
all the required patches are merged<br class=3D"">
><br class=3D"">
><br class=3D"">
</span><span class=3D"">> The authors should use Bug-Url on
the main =
bug and related-to: on other<br class=3D"">
> patches that are related.<br class=3D"">
<br class=3D"">
</span>This is not possible. Many times you need series of patches to =
fix a bug, and<br class=3D"">
you the number of patches may change during development. You start with =
one<br class=3D"">
patch, and later you find that you need another one, so all of them will =
have<br class=3D"">
a bug url.<br class=3D"">
<br class=3D"">
Practically, you should expect that all patches in the series will<br =
class=3D"">
have a bug-url.<br class=3D"">
If the hook will change the bug incorrectly someone will have to fix =
this, and<br class=3D"">
it is very unlikely that a developer will go to clean after the hook.<br =
class=3D"">
<span class=3D""><br class=3D"">
>> and backported to the correct repositories.<br
class=3D"">
><br class=3D"">
><br class=3D"">
</span><span class=3D"">> This is done with logic according
to the =
bug target milestone.<br class=3D"">
><br class=3D"">
> for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug =
targeted to<br class=3D"">
> ovirt-4.0.2.<br class=3D"">
> The hook should check if branch 4.0.2 exists or not, if it exists =
then the<br class=3D"">
> bug should NOT move to MODIFIED,<br class=3D"">
> since it needs still backporting to ovirt-engine-4.0.2 branch.<br =
class=3D"">
<br class=3D"">
</span>This is too fragile. For example, maybe a 4.0.2 branch is created =
after<br class=3D"">
the patch was merged to 4.0 branch, and the patch will be missing, =
although<br class=3D"">
the bug is already set to modified.<br class=3D"">
<br class=3D"">
Setting to modified should be done by the owner of the bug, after =
verifying<br class=3D"">
that the patches exists in correct branch.<br class=3D"">
<br class=3D"">
I'm not suggesting to remove the hook, just disable the feature of =
making<br class=3D"">
a bug modified.<br class=3D""></blockquote><div
class=3D""><br =
class=3D""></div><div class=3D"">+1. On build day
checking that bugs in =
modified not listed in Bug-Url on the build branch due to missing =
backport is a painful =
experience.</div></div></div></div></div></blockquote><div><br
=
class=3D""></div>it is a tradeoff. It was mentioned before that the =
other way around we would be left with too many POSTed bugs which are =
actually already merged. The maintainer is typically not the assignee so =
if you e.g. merge the last patch on Thursday afternoon it takes some =
time to gets attention, in the meantime there is a build which won=E2=80=99=
t consider that bug.</div><div><br
class=3D""></div><div><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D""><br
class=3D""></div><div =
class=3D""> </div><blockquote
class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"
class=3D""><br class=3D"">
Nir<br class=3D"">
</font></span></blockquote></div><br
class=3D""><br clear=3D"all" =
class=3D""><div class=3D""><br
class=3D""></div>-- <br class=3D""><div =
class=3D"gmail_signature"
data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr" class=3D""><div class=3D""><div
dir=3D"ltr" class=3D"">Sandro =
Bonazzola<br class=3D"">Better technology. Faster innovation. Powered by
=
community collaboration.<br class=3D"">See how it works at <a =
href=3D"http://redhat.com/" target=3D"_blank"
class=3D"">redhat.com</a><br=
class=3D""></div></div></div></div>
</div></div>
_______________________________________________<br class=3D"">Devel =
mailing list<br class=3D""><a href=3D"mailto:Devel@ovirt.org"
=
class=3D"">Devel(a)ovirt.org</a><br =
class=3D"">http://lists.ovirt.org/mailman/listinfo/devel<...
</div><br class=3D""></body></html>=
--Apple-Mail=_745D14C7-E31B-46BD-9AD9-F1992E0F2C73--
10:32 a.m.
On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com> wrote:
> >
> >
> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
> >>
> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com> wrote:
> >> > I still thinks its a very valuable hook and we are aware of the fact
> it
> >> > has
> >> > bugs, especially with patches on master branch and 4.0.
> >> >
> >> > Shlomi from the infra team is working on a solution for it as we
> speak
> >> > and
> >> > we hope to have a solution in the next few days, however it's not
> >> > trival to
> >> > test and requires setting up a staging env and improve loga for the
> >> > hooks
> >> > system.
> >>
> >> How do you plan to solve this?
> >>
> >> Only the owner of the bug knows if the all the required patches are
> merged
> >
> >
> > The authors should use Bug-Url on the main bug and related-to: on other
> > patches that are related.
>
> This is not possible. Many times you need series of patches to fix a bug,
> and
> you the number of patches may change during development. You start with
> one
> patch, and later you find that you need another one, so all of them will
> have
> a bug url.
>
> Practically, you should expect that all patches in the series will
> have a bug-url.
> If the hook will change the bug incorrectly someone will have to fix
> this, and
> it is very unlikely that a developer will go to clean after the hook.
>
> >> and backported to the correct repositories.
> >
> >
> > This is done with logic according to the bug target milestone.
> >
> > for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug
> targeted to
> > ovirt-4.0.2.
> > The hook should check if branch 4.0.2 exists or not, if it exists then
> the
> > bug should NOT move to MODIFIED,
> > since it needs still backporting to ovirt-engine-4.0.2 branch.
>
> This is too fragile. For example, maybe a 4.0.2 branch is created after
> the patch was merged to 4.0 branch, and the patch will be missing,
> although
> the bug is already set to modified.
>
> Setting to modified should be done by the owner of the bug, after
> verifying
> that the patches exists in correct branch.
>
> I'm not suggesting to remove the hook, just disable the feature of making
> a bug modified.
>
+1. On build day checking that bugs in modified not listed in Bug-Url on
the build branch due to missing backport is a painful experience.
it is a tradeoff. It was mentioned before that the other way around we
would be left with too many POSTed bugs which are actually already merged.
The maintainer is typically not the assignee so if you e.g. merge the last
patch on Thursday afternoon it takes some time to gets attention, in the
meantime there is a build which won’t consider that bug.
The other way around is having a modified bugs which should have been in
post being considered in the build, moved to QE, failing QE, move back to
assigned.
Not sure it's much better.
>
> Nir
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10:37 a.m.
It will be very and and actually save the infra alot of coding and effort
to stop using this hook,
But I really think it will introduce another problem of bugs on POST.
If we can find a logic that will be the silver bullet for all the use cases
then lets do it, if not, we have to make sure ALL maintainers are aware
they HAVE to monitor bugs in POST
and move then on time, probably will need a WHINE also.
On Thu, Aug 18, 2016 at 10:32 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
>
> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
>
>
>
> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>
>> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com> wrote:
>> >
>> >
>> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com>
wrote:
>> >>
>> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com>
wrote:
>> >> > I still thinks its a very valuable hook and we are aware of the
fact
>> it
>> >> > has
>> >> > bugs, especially with patches on master branch and 4.0.
>> >> >
>> >> > Shlomi from the infra team is working on a solution for it as we
>> speak
>> >> > and
>> >> > we hope to have a solution in the next few days, however it's
not
>> >> > trival to
>> >> > test and requires setting up a staging env and improve loga for
the
>> >> > hooks
>> >> > system.
>> >>
>> >> How do you plan to solve this?
>> >>
>> >> Only the owner of the bug knows if the all the required patches are
>> merged
>> >
>> >
>> > The authors should use Bug-Url on the main bug and related-to: on
other
>> > patches that are related.
>>
>> This is not possible. Many times you need series of patches to fix a
bug,
>> and
>> you the number of patches may change during development. You start with
>> one
>> patch, and later you find that you need another one, so all of them will
>> have
>> a bug url.
>>
>> Practically, you should expect that all patches in the series will
>> have a bug-url.
>> If the hook will change the bug incorrectly someone will have to fix
>> this, and
>> it is very unlikely that a developer will go to clean after the hook.
>>
>> >> and backported to the correct repositories.
>> >
>> >
>> > This is done with logic according to the bug target milestone.
>> >
>> > for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug
>> targeted to
>> > ovirt-4.0.2.
>> > The hook should check if branch 4.0.2 exists or not, if it exists then
>> the
>> > bug should NOT move to MODIFIED,
>> > since it needs still backporting to ovirt-engine-4.0.2 branch.
>>
>> This is too fragile. For example, maybe a 4.0.2 branch is created after
>> the patch was merged to 4.0 branch, and the patch will be missing,
>> although
>> the bug is already set to modified.
>>
>> Setting to modified should be done by the owner of the bug, after
>> verifying
>> that the patches exists in correct branch.
>>
>> I'm not suggesting to remove the hook, just disable the feature of
making
>> a bug modified.
>>
>
> +1. On build day checking that bugs in modified not listed in Bug-Url on
> the build branch due to missing backport is a painful experience.
>
>
> it is a tradeoff. It was mentioned before that the other way around we
> would be left with too many POSTed bugs which are actually already merged
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
10:38 a.m.
On Thu, Aug 18, 2016 at 10:37 AM, Eyal Edri <eedri(a)redhat.com> wrote:
It will be very and and actually save the infra alot of coding and
effort
to stop using this hook,
s very/very easy
But I really think it will introduce another problem of bugs on
POST.
If we can find a logic that will be the silver bullet for all the use
cases then lets do it, if not, we have to make sure ALL maintainers are
aware they HAVE to monitor bugs in POST
and move then on time, probably will need a WHINE also.
On Thu, Aug 18, 2016 at 10:32 AM, Sandro Bonazzola <sbonazzo(a)redhat.com>
wrote:
> On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek <
> michal.skrivanek(a)redhat.com> wrote:
>
> >
> > On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
> >
> >
> >
> > On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
> >
> >> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com> wrote:
> >> >
> >> >
> >> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com>
> wrote:
> >> >>
> >> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri
<eedri(a)redhat.com>
> wrote:
> >> >> > I still thinks its a very valuable hook and we are aware of
the
> fact
> >> it
> >> >> > has
> >> >> > bugs, especially with patches on master branch and 4.0.
> >> >> >
> >> >> > Shlomi from the infra team is working on a solution for it as
we
> >> speak
> >> >> > and
> >> >> > we hope to have a solution in the next few days, however
it's not
> >> >> > trival to
> >> >> > test and requires setting up a staging env and improve loga
for
> the
> >> >> > hooks
> >> >> > system.
> >> >>
> >> >> How do you plan to solve this?
> >> >>
> >> >> Only the owner of the bug knows if the all the required patches
are
> >> merged
> >> >
> >> >
> >> > The authors should use Bug-Url on the main bug and related-to: on
> other
> >> > patches that are related.
> >>
> >> This is not possible. Many times you need series of patches to fix a
> bug,
> >> and
> >> you the number of patches may change during development. You start with
> >> one
> >> patch, and later you find that you need another one, so all of them
> will
> >> have
> >> a bug url.
> >>
> >> Practically, you should expect that all patches in the series will
> >> have a bug-url.
> >> If the hook will change the bug incorrectly someone will have to fix
> >> this, and
> >> it is very unlikely that a developer will go to clean after the hook.
> >>
> >> >> and backported to the correct repositories.
> >> >
> >> >
> >> > This is done with logic according to the bug target milestone.
> >> >
> >> > for e.g - a patch on branch 'ovirt-engine-4.0' was merged to
bug
> >> targeted to
> >> > ovirt-4.0.2.
> >> > The hook should check if branch 4.0.2 exists or not, if it exists
> then
> >> the
> >> > bug should NOT move to MODIFIED,
> >> > since it needs still backporting to ovirt-engine-4.0.2 branch.
> >>
> >> This is too fragile. For example, maybe a 4.0.2 branch is created after
> >> the patch was merged to 4.0 branch, and the patch will be missing,
> >> although
> >> the bug is already set to modified.
> >>
> >> Setting to modified should be done by the owner of the bug, after
> >> verifying
> >> that the patches exists in correct branch.
> >>
> >> I'm not suggesting to remove the hook, just disable the feature of
> making
> >> a bug modified.
> >>
> >
> > +1. On build day checking that bugs in modified not listed in Bug-Url on
> > the build branch due to missing backport is a painful experience.
> >
> >
> > it is a tradeoff. It was mentioned before that the other way around we
> > would be left with too many POSTed bugs which are actually already
> merged
>
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
10:38 a.m.
--Apple-Mail=_B5C5EE46-B870-4828-AD47-B51209767DB1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
<http://lists.ovirt.org/mailman/listinfo/devel>
On 18 Aug 2016, at 09:32, Sandro Bonazzola
<sbonazzo(a)redhat.com> =
wrote:
=20
=20
=20
On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek =
<michal.skrivanek(a)redhat.com
<mailto:michal.skrivanek@redhat.com>> =
wrote:
=20
> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo(a)redhat.com =
<mailto:sbonazzo@redhat.com>> wrote:
>=20
>=20
>=20
> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com =
<mailto:nsoffer@redhat.com>> wrote:
> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com =
<mailto:eedri@redhat.com>> wrote:
> >
> >
> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com =
<mailto:nsoffer@redhat.com>> wrote:
> >>
> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com =
<mailto:eedri@redhat.com>> wrote:
> >> > I still thinks its a very valuable hook and we are
aware of the =
fact it
> >> > has
> >> > bugs, especially with patches on master branch and 4.0.
> >> >
> >> > Shlomi from the infra team is working on a solution for it as we =
speak
> >> > and
> >> > we hope to have a solution in the next few days, however it's =
not
> >> > trival to
> >> > test and requires setting up a staging env and improve loga for =
the
> >> > hooks
> >> > system.
> >>
> >> How do you plan to solve this?
> >>
> >> Only the owner of the bug knows if the all the required patches =
are
merged
> >
> >
> > The authors should use Bug-Url on the main bug and related-to: on =
other
> > patches that are related.
>=20
> This is not possible. Many times you need series of patches to fix a =
bug,
and
> you the number of patches may change during development. You
start =
with one
> patch, and later you find that you need another one, so all of
them =
will have
> a bug url.
>=20
> Practically, you should expect that all patches in the series will
> have a bug-url.
> If the hook will change the bug incorrectly someone will have to fix =
this,
and
> it is very unlikely that a developer will go to clean after the
hook.
>=20
> >> and backported to the correct repositories.
> >
> >
> > This is done with logic according to the bug target milestone.
> >
> > for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug =
targeted to
> > ovirt-4.0.2.
> > The hook should check if branch 4.0.2 exists or not, if it exists =
then
the
> > bug should NOT move to MODIFIED,
> > since it needs still backporting to ovirt-engine-4.0.2 branch.
>=20
> This is too fragile. For example, maybe a 4.0.2 branch is created =
after
> the patch was merged to 4.0 branch, and the patch will be
missing, =
although
> the bug is already set to modified.
>=20
> Setting to modified should be done by the owner of the bug, after =
verifying
> that the patches exists in correct branch.
>=20
> I'm not suggesting to remove the hook, just disable the feature of =
making
> a bug modified.
>=20
> +1. On build day checking that bugs in modified not listed in Bug-Url =
on the
build branch due to missing backport is a painful experience.
=20
it is a tradeoff. It was mentioned before that the other way around we =
would be
left with too many POSTed bugs which are actually already =
merged. The maintainer is typically not the assignee so if you e.g. =
merge the last patch on Thursday afternoon it takes some time to gets =
attention, in the meantime there is a build which won=E2=80=99t consider =
that bug.
=20
=20
The other way around is having a modified bugs which should have been =
in post
being considered in the build, moved to QE, failing QE, move =
back to assigned.
Not sure it's much better.
it is when the amount of false positive ON_QA bugs is far less than =
amount of forgotten bugs
I=E2=80=99m not advocating for it, I=E2=80=99m just saying it was =
pointed out that this was the situation before we introduced the hook.
Perhaps with the doc police emails it is no longer a relevant point
Thanks,
michal
=20
=20
=20
=20
>=20
> =20
>=20
> Nir
>=20
>=20
>=20
> --=20
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community =
collaboration.
See how it works at redhat.com
<http://redhat.com/>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org <mailto:Devel@ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/devel =
=20
=20
=20
--=20
Sandro Bonazzola
Better technology. Faster innovation. Powered by community =
collaboration.
See how it works at redhat.com <http://redhat.com/>
--Apple-Mail=_B5C5EE46-B870-4828-AD47-B51209767DB1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type"
content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote
type=3D"cite" class=3D""><div =
class=3D"">On 18 Aug 2016, at 09:32, Sandro Bonazzola <<a =
href=3D"mailto:sbonazzo@redhat.com"
class=3D"">sbonazzo(a)redhat.com</a>&gt;=
wrote:</div><br class=3D"Apple-interchange-newline"><div
class=3D""><div =
dir=3D"ltr" class=3D""><br class=3D""><div
class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Thu, Aug 18, 2016 at
9:19 AM, =
Michal Skrivanek <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:michal.skrivanek@redhat.com" target=3D"_blank" =
class=3D"">michal.skrivanek(a)redhat.com</a>&gt;</span>
wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word" class=3D""><br
class=3D""><div =
class=3D""><div class=3D""><div
class=3D"h5"><blockquote type=3D"cite" =
class=3D""><div class=3D"">On 18 Aug 2016, at 09:09, Sandro
Bonazzola =
<<a href=3D"mailto:sbonazzo@redhat.com" target=3D"_blank" =
class=3D"">sbonazzo(a)redhat.com</a>&gt; wrote:</div><br
class=3D""><div =
class=3D""><div dir=3D"ltr" class=3D""><br
class=3D""><div =
class=3D"gmail_extra"><br class=3D""><div
class=3D"gmail_quote">On Wed, =
Aug 17, 2016 at 5:12 PM, Nir Soffer <span dir=3D"ltr"
class=3D""><<a =
href=3D"mailto:nsoffer@redhat.com" target=3D"_blank" =
class=3D"">nsoffer(a)redhat.com</a>&gt;</span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote"
style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class=3D"">On =
Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <<a =
href=3D"mailto:eedri@redhat.com" target=3D"_blank" =
class=3D"">eedri(a)redhat.com</a>&gt; wrote:<br
class=3D"">
><br class=3D"">
><br class=3D"">
> On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <<a =
href=3D"mailto:nsoffer@redhat.com" target=3D"_blank" =
class=3D"">nsoffer(a)redhat.com</a>&gt; wrote:<br
class=3D"">
>><br class=3D"">
</span><span class=3D"">>> On Wed, Aug 17, 2016 at
1:45 PM, Eyal =
Edri <<a href=3D"mailto:eedri@redhat.com" target=3D"_blank"
=
class=3D"">eedri(a)redhat.com</a>&gt; wrote:<br
class=3D"">
>> > I still thinks its a very valuable hook and we are aware =
of the fact it<br class=3D"">
>> > has<br class=3D"">
>> > bugs, especially with patches on master branch and =
4.0.<br class=3D"">
>> ><br class=3D"">
>> > Shlomi from the infra team is working on a solution for it =
as we speak<br class=3D"">
>> > and<br class=3D"">
>> > we hope to have a solution in the next few days, =
however it's not<br class=3D"">
>> > trival to<br class=3D"">
>> > test and requires setting up a staging env and improve =
loga for the<br class=3D"">
>> > hooks<br class=3D"">
>> > system.<br class=3D"">
>><br class=3D"">
>> How do you plan to solve this?<br class=3D"">
>><br class=3D"">
</span><span class=3D"">>> Only the owner of the bug
knows if the =
all the required patches are merged<br class=3D"">
><br class=3D"">
><br class=3D"">
</span><span class=3D"">> The authors should use Bug-Url on
the main =
bug and related-to: on other<br class=3D"">
> patches that are related.<br class=3D"">
<br class=3D"">
</span>This is not possible. Many times you need series of patches to =
fix a bug, and<br class=3D"">
you the number of patches may change during development. You start with =
one<br class=3D"">
patch, and later you find that you need another one, so all of them will =
have<br class=3D"">
a bug url.<br class=3D"">
<br class=3D"">
Practically, you should expect that all patches in the series will<br =
class=3D"">
have a bug-url.<br class=3D"">
If the hook will change the bug incorrectly someone will have to fix =
this, and<br class=3D"">
it is very unlikely that a developer will go to clean after the hook.<br =
class=3D"">
<span class=3D""><br class=3D"">
>> and backported to the correct repositories.<br
class=3D"">
><br class=3D"">
><br class=3D"">
</span><span class=3D"">> This is done with logic according
to the =
bug target milestone.<br class=3D"">
><br class=3D"">
> for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug =
targeted to<br class=3D"">
> ovirt-4.0.2.<br class=3D"">
> The hook should check if branch 4.0.2 exists or not, if it exists =
then the<br class=3D"">
> bug should NOT move to MODIFIED,<br class=3D"">
> since it needs still backporting to ovirt-engine-4.0.2 branch.<br =
class=3D"">
<br class=3D"">
</span>This is too fragile. For example, maybe a 4.0.2 branch is created =
after<br class=3D"">
the patch was merged to 4.0 branch, and the patch will be missing, =
although<br class=3D"">
the bug is already set to modified.<br class=3D"">
<br class=3D"">
Setting to modified should be done by the owner of the bug, after =
verifying<br class=3D"">
that the patches exists in correct branch.<br class=3D"">
<br class=3D"">
I'm not suggesting to remove the hook, just disable the feature of =
making<br class=3D"">
a bug modified.<br class=3D""></blockquote><div
class=3D""><br =
class=3D""></div><div class=3D"">+1. On build day
checking that bugs in =
modified not listed in Bug-Url on the build branch due to missing =
backport is a painful =
experience.</div></div></div></div></div></blockquote><div
class=3D""><br =
class=3D""></div></div></div>it is a tradeoff. It was
mentioned before =
that the other way around we would be left with too many POSTed bugs =
which are actually already merged. The maintainer is typically not the =
assignee so if you e.g. merge the last patch on Thursday afternoon it =
takes some time to gets attention, in the meantime there is a build =
which won=E2=80=99t consider that bug.</div><div class=3D""><br
=
class=3D""></div></div></blockquote><div
class=3D""><br =
class=3D""></div><div class=3D"">The other way around
is having a =
modified bugs which should have been in post being considered in the =
build, moved to QE, failing QE, move back to assigned.</div><div =
class=3D"">Not sure it's much =
better.</div></div></div></div></div></blockquote><div><br
=
class=3D""></div>it is when the amount of false positive ON_QA bugs is
=
far less than amount of forgotten bugs</div><div>I=E2=80=99m not =
advocating for it, I=E2=80=99m just saying it was pointed out that this =
was the situation before we introduced the hook.</div><div>Perhaps with =
the doc police emails it is no longer a relevant point</div><div><br =
class=3D""></div><div>Thanks,</div><div>michal</div><div><br
=
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><div =
dir=3D"ltr" class=3D""><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D""><br
class=3D""></div><div =
class=3D""><br class=3D""></div><div
class=3D""> </div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div style=3D"word-wrap:break-word" =
class=3D""><div class=3D""></div><div
class=3D""><br =
class=3D""><blockquote type=3D"cite"
class=3D""><div class=3D""><span =
class=3D""><div dir=3D"ltr" class=3D""><div
class=3D"gmail_extra"><div =
class=3D"gmail_quote"><div class=3D""><br
class=3D""></div><div =
class=3D""> </div><blockquote
class=3D"gmail_quote" style=3D"margin:0=
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><font color=3D"#888888"
class=3D""><br class=3D"">
Nir<br class=3D"">
</font></span></blockquote></div><br
class=3D""><br clear=3D"all" =
class=3D""><div class=3D""><br
class=3D""></div>-- <br class=3D""><div =
data-smartmail=3D"gmail_signature" class=3D""><div
dir=3D"ltr" =
class=3D""><div class=3D""><div dir=3D"ltr"
class=3D"">Sandro =
Bonazzola<br class=3D"">Better technology. Faster innovation. Powered by
=
community collaboration.<br class=3D"">See how it works at <a =
href=3D"http://redhat.com/" target=3D"_blank"
class=3D"">redhat.com</a><br=
class=3D""></div></div></div></div>
</div></div></span><span class=3D"">
______________________________<wbr class=3D"">_________________<br =
class=3D"">Devel mailing list<br class=3D""><a =
href=3D"mailto:Devel@ovirt.org" target=3D"_blank" =
class=3D"">Devel(a)ovirt.org</a><br class=3D""><a =
href=3D"http://lists.ovirt.org/mailman/listinfo/devel"
target=3D"_blank" =
class=3D"">http://lists.ovirt.org/<wbr =
class=3D"">mailman/listinfo/devel</a></span></div></blockquote></div><br
=
class=3D""></div></blockquote></div><br
class=3D""><br clear=3D"all" =
class=3D""><div class=3D""><br
class=3D""></div>-- <br class=3D""><div =
class=3D"gmail_signature"
data-smartmail=3D"gmail_signature"><div =
dir=3D"ltr" class=3D""><div class=3D""><div
dir=3D"ltr" class=3D"">Sandro =
Bonazzola<br class=3D"">Better technology. Faster innovation. Powered by
=
community collaboration.<br class=3D"">See how it works at <a =
href=3D"http://redhat.com/" target=3D"_blank"
class=3D"">redhat.com</a><br=
class=3D""></div></div></div></div>
</div></div>
</div></blockquote></div><br
class=3D""></body></html>=
--Apple-Mail=_B5C5EE46-B870-4828-AD47-B51209767DB1--
10:45 a.m.
On Thu, Aug 18, 2016 at 10:38 AM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
On 18 Aug 2016, at 09:32, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
>
> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
>
>
>
> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>
>> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com> wrote:
>> >
>> >
>> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com>
>> wrote:
>> >>
>> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com>
wrote:
>> >> > I still thinks its a very valuable hook and we are aware of the
>> fact it
>> >> > has
>> >> > bugs, especially with patches on master branch and 4.0.
>> >> >
>> >> > Shlomi from the infra team is working on a solution for it as we
>> speak
>> >> > and
>> >> > we hope to have a solution in the next few days, however it's
not
>> >> > trival to
>> >> > test and requires setting up a staging env and improve loga for
the
>> >> > hooks
>> >> > system.
>> >>
>> >> How do you plan to solve this?
>> >>
>> >> Only the owner of the bug knows if the all the required patches are
>> merged
>> >
>> >
>> > The authors should use Bug-Url on the main bug and related-to: on other
>> > patches that are related.
>>
>> This is not possible. Many times you need series of patches to fix a
>> bug, and
>> you the number of patches may change during development. You start with
>> one
>> patch, and later you find that you need another one, so all of them will
>> have
>> a bug url.
>>
>> Practically, you should expect that all patches in the series will
>> have a bug-url.
>> If the hook will change the bug incorrectly someone will have to fix
>> this, and
>> it is very unlikely that a developer will go to clean after the hook.
>>
>> >> and backported to the correct repositories.
>> >
>> >
>> > This is done with logic according to the bug target milestone.
>> >
>> > for e.g - a patch on branch 'ovirt-engine-4.0' was merged to bug
>> targeted to
>> > ovirt-4.0.2.
>> > The hook should check if branch 4.0.2 exists or not, if it exists then
>> the
>> > bug should NOT move to MODIFIED,
>> > since it needs still backporting to ovirt-engine-4.0.2 branch.
>>
>> This is too fragile. For example, maybe a 4.0.2 branch is created after
>> the patch was merged to 4.0 branch, and the patch will be missing,
>> although
>> the bug is already set to modified.
>>
>> Setting to modified should be done by the owner of the bug, after
>> verifying
>> that the patches exists in correct branch.
>>
>> I'm not suggesting to remove the hook, just disable the feature of making
>> a bug modified.
>>
>
> +1. On build day checking that bugs in modified not listed in Bug-Url on
> the build branch due to missing backport is a painful experience.
>
>
> it is a tradeoff. It was mentioned before that the other way around we
> would be left with too many POSTed bugs which are actually already merged.
> The maintainer is typically not the assignee so if you e.g. merge the last
> patch on Thursday afternoon it takes some time to gets attention, in the
> meantime there is a build which won’t consider that bug.
>
>
The other way around is having a modified bugs which should have been in
post being considered in the build, moved to QE, failing QE, move back to
assigned.
Not sure it's much better.
it is when the amount of false positive ON_QA bugs is far less than amount
of forgotten bugs
I’m not advocating for it, I’m just saying it was pointed out that this
was the situation before we introduced the hook.
Perhaps with the doc police emails it is no longer a relevant point
Do we have a list of number of bugs that actually failed ON_QA due to this?
Thanks,
michal
>
>
>
>
>>
>> Nir
>>
>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
2:09 p.m.
On Thu, Aug 18, 2016 at 9:45 AM, Eyal Edri <eedri(a)redhat.com> wrote:
On Thu, Aug 18, 2016 at 10:38 AM, Michal Skrivanek <
michal.skrivanek(a)redhat.com> wrote:
>
> On 18 Aug 2016, at 09:32, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
>
>
>
> On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek <
> michal.skrivanek(a)redhat.com> wrote:
>
>>
>> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo(a)redhat.com> wrote:
>>
>>
>>
>> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com> wrote:
>>
>>> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com> wrote:
>>> >
>>> >
>>> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com>
>>> wrote:
>>> >>
>>> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com>
wrote:
>>> >> > I still thinks its a very valuable hook and we are aware of
the
>>> fact it
>>> >> > has
>>> >> > bugs, especially with patches on master branch and 4.0.
>>> >> >
>>> >> > Shlomi from the infra team is working on a solution for it as
we
>>> speak
>>> >> > and
>>> >> > we hope to have a solution in the next few days, however
it's not
>>> >> > trival to
>>> >> > test and requires setting up a staging env and improve loga for
the
>>> >> > hooks
>>> >> > system.
>>> >>
>>> >> How do you plan to solve this?
>>> >>
>>> >> Only the owner of the bug knows if the all the required patches are
>>> merged
>>> >
>>> >
>>> > The authors should use Bug-Url on the main bug and related-to: on
>>> other
>>> > patches that are related.
>>>
>>> This is not possible. Many times you need series of patches to fix a
>>> bug, and
>>> you the number of patches may change during development. You start with
>>> one
>>> patch, and later you find that you need another one, so all of them
>>> will have
>>> a bug url.
>>>
>>> Practically, you should expect that all patches in the series will
>>> have a bug-url.
>>> If the hook will change the bug incorrectly someone will have to fix
>>> this, and
>>> it is very unlikely that a developer will go to clean after the hook.
>>>
>>> >> and backported to the correct repositories.
>>> >
>>> >
>>> > This is done with logic according to the bug target milestone.
>>> >
>>> > for e.g - a patch on branch 'ovirt-engine-4.0' was merged to
bug
>>> targeted to
>>> > ovirt-4.0.2.
>>> > The hook should check if branch 4.0.2 exists or not, if it exists
>>> then the
>>> > bug should NOT move to MODIFIED,
>>> > since it needs still backporting to ovirt-engine-4.0.2 branch.
>>>
>>> This is too fragile. For example, maybe a 4.0.2 branch is created after
>>> the patch was merged to 4.0 branch, and the patch will be missing,
>>> although
>>> the bug is already set to modified.
>>>
>>> Setting to modified should be done by the owner of the bug, after
>>> verifying
>>> that the patches exists in correct branch.
>>>
>>> I'm not suggesting to remove the hook, just disable the feature of
>>> making
>>> a bug modified.
>>>
>>
>> +1. On build day checking that bugs in modified not listed in Bug-Url on
>> the build branch due to missing backport is a painful experience.
>>
>>
>> it is a tradeoff. It was mentioned before that the other way around we
>> would be left with too many POSTed bugs which are actually already merged.
>> The maintainer is typically not the assignee so if you e.g. merge the last
>> patch on Thursday afternoon it takes some time to gets attention, in the
>> meantime there is a build which won’t consider that bug.
>>
>>
> The other way around is having a modified bugs which should have been in
> post being considered in the build, moved to QE, failing QE, move back to
> assigned.
> Not sure it's much better.
>
>
> it is when the amount of false positive ON_QA bugs is far less than
> amount of forgotten bugs
> I’m not advocating for it, I’m just saying it was pointed out that this
> was the situation before we introduced the hook.
> Perhaps with the doc police emails it is no longer a relevant point
>
>
Do we have a list of number of bugs that actually failed ON_QA due to
this?
No I haven't
> Thanks,
> michal
>
>
>
>
>
>>
>>
>>
>>
>>>
>>> Nir
>>>
>>
>>
>>
>> --
>> Sandro Bonazzola
>> Better technology. Faster innovation. Powered by community collaboration.
>> See how it works at redhat.com
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
>>
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
Eyal Edri
Associate Manager
RHV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
<https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>
2:40 p.m.
Hi All,
I'm currently working to solve this issue.
I will update you when done :)
Best Regards,
Shlomi Ben-David | Software Engineer | Red Hat ISRAEL
Red Hat Certified System Administrator | Red Hat Certified Engineer
IRC: shlomibendavid (on #rhev-integ, #rhev-dev, #rhev-ci)
OPEN SOURCE - 1 4 011 && 011 4 1
On Wed, Aug 17, 2016 at 10:10 AM, Yedidyah Bar David <didi(a)redhat.com>
wrote:
Hi all,
We currently have a bot that automatically moves bugs from POST to MODIFIED
if all linked patches on gerrit are merged.
It happened to me personally several times that this was a wrong thing to
do,
either because a new patch was still needed but not pushed yet, or because
an existing patch should have been back-ported to another branch and wasn't
yet. Since I usually pay more attention to my bug in POST, I sometimes
missed
this and handled the missing patches (backports, usually) later than I
could
if left on POST.
I have a feeling I am not the only one. So I suggest to stop doing this.
I can think of several alternatives:
1. Do nothing. I think that's reasonable - I think most people pay more
attention to POST bugs anyway.
2. Set needinfo on bug owner.
3. Send some alert email to relevant people (bug owner, existing patches
owners,
perhaps others - e.g. reviewers of existing patches, perhaps those
that actually reviewed, etc.). Need to think how to make it not too
annoying for others but
still effective also if owner is on long PTO or something like that. New
flag
doesn't have to be very specific - can be called something like 'attention
needed' or something like that.
4. Add a new flag for that and set it. This will allow easier
filtering/reporting.
What do you think?
--
Didi
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
2990
days inactive
3018
days old
17 comments
8 participants
participants (8)
-
Eli Mesika -
Eyal Edri -
Michal Skrivanek -
Nir Soffer -
Sandro Bonazzola -
Shlomo Ben David -
Sven Kieske -
Yedidyah Bar David