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

Wed Sep 14 11:09:34 UTC 2016

On Thu, Aug 18, 2016 at 9:45 AM, Eyal Edri <eedri at redhat.com> wrote:

>
>
> 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?
>

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 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)
>

-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20160914/9dc4fcab/attachment-0001.html>