[ovirt-devel] Alternatives to automatically move bugs to MODIFIED

[Eyal Edri]

On Thu, Aug 18, 2016 at 10:38 AM, Michal Skrivanek <
michal.skrivanek at redhat.com> wrote:

>
> On 18 Aug 2016, at 09:32, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>
>
>
> On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek <
> michal.skrivanek at redhat.com> wrote:
>
>>
>> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo at redhat.com> wrote:
>>
>>
>>
>> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer at redhat.com> wrote:
>>
>>> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri at redhat.com> wrote:
>>> >
>>> >
>>> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer at redhat.com>
>>> wrote:
>>> >>
>>> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri at 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 at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160818/3c345faf/attachment-0001.html>