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

Sandro Bonazzola sbonazzo at redhat.com
Thu Aug 18 07:09:44 UTC 2016


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.



>
> Nir
>



-- 
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/63c5e7f9/attachment-0001.html>


More information about the Devel mailing list