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

On Thu, Aug 18, 2016 at 10:38 AM, Michal Skrivanek < michal.skrivanek(a)redhat.com&gt; wrote: > > On 18 Aug 2016, at 09:32, Sandro Bonazzola <sbonazzo(a)redhat.com&gt; wrote: > > > > On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek < > michal.skrivanek(a)redhat.com&gt; wrote: > >> >> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbonazzo(a)redhat.com&gt; wrote: >> >> >> >> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: >> >>> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <eedri(a)redhat.com&gt; wrote: >>> > >>> > >>> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsoffer(a)redhat.com&gt; >>> wrote: >>> >> >>> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <eedri(a)redhat.com&gt; 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)