On Thu, Aug 18, 2016 at 9:45 AM, Eyal Edri <ee...@redhat.com> wrote: > > > On Thu, Aug 18, 2016 at 10:38 AM, Michal Skrivanek < > michal.skriva...@redhat.com> wrote: > >> >> On 18 Aug 2016, at 09:32, Sandro Bonazzola <sbona...@redhat.com> wrote: >> >> >> >> On Thu, Aug 18, 2016 at 9:19 AM, Michal Skrivanek < >> michal.skriva...@redhat.com> wrote: >> >>> >>> On 18 Aug 2016, at 09:09, Sandro Bonazzola <sbona...@redhat.com> wrote: >>> >>> >>> >>> On Wed, Aug 17, 2016 at 5:12 PM, Nir Soffer <nsof...@redhat.com> wrote: >>> >>>> On Wed, Aug 17, 2016 at 2:47 PM, Eyal Edri <ee...@redhat.com> wrote: >>>> > >>>> > >>>> > On Wed, Aug 17, 2016 at 2:25 PM, Nir Soffer <nsof...@redhat.com> >>>> wrote: >>>> >> >>>> >> On Wed, Aug 17, 2016 at 1:45 PM, Eyal Edri <ee...@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@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@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>
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
