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

[Sandro Bonazzola]

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.




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