<p dir="ltr"><br>
On Jan 12, 2016 2:50 AM, "Niels de Vos" <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
><br>
> On Fri, Jan 08, 2016 at 12:46:09PM +0530, Raghavendra Talur wrote:<br>
> > On Fri, Jan 8, 2016 at 12:28 PM, Kaushal M <<a href="mailto:kshlmster@gmail.com">kshlmster@gmail.com</a>> wrote:<br>
> ><br>
> > > On Fri, Jan 8, 2016 at 12:10 PM, Kaushal M <<a href="mailto:kshlmster@gmail.com">kshlmster@gmail.com</a>> wrote:<br>
> > > > On Fri, Jan 8, 2016 at 12:03 PM, Raghavendra Talur <<a href="mailto:rtalur@redhat.com">rtalur@redhat.com</a>><br>
> > > wrote:<br>
> > > >> Top posting, this is a very old thread.<br>
> > > >><br>
> > > >> Keeping in view the recent NetBSD problems and the number of bugs<br>
> > > creeping<br>
> > > >> in, I suggest we do these things right now:<br>
> > > >><br>
> > > >> a. Change the gerrit merge type to fast forward only.<br>
> > > >> As explained below in the thread, with our current setup even if both<br>
> > > PatchA<br>
> > > >> and PatchB pass regression separately when both are merged it is<br>
> > > possible<br>
> > > >> that a functional bug creeps in.<br>
> > > >> This is the only solution to prevent that from happening.<br>
> > > >> I will work with Kaushal to get this done.<br>
> > > >><br>
> > > >> b. In Jenkins, remove gerrit trigger and make it a manual operation<br>
> > > ><br>
> > > > Making it manual might be too much work for maintainers. I suggest (as<br>
> > > > I've suggested before) we make regressions trigger when a change has<br>
> > > > been reviewed +2 by a maintainer.<br>
> > > ><br>
> > ><br>
> ><br>
> > Makes sense. I have disabled it completely for now and lets keep it that<br>
> > way till<br>
> > developers realize it(a day should be enough). We will change this trigger<br>
> > to on Code Review +2 by tomorrow.<br>
><br>
> Aaaaah! And I have been wondering why patches don't get verified<br>
> anymore :-/<br>
><br>
> An email to the maintainers list as a heads up would have been welcome.<br>
><br>
> How would we handle patches that get sent by maintainers? Most<br>
> developers that do code reviews will only +1 those changes. Those will<br>
> never get automatically regression tested then. I dont think a<br>
> maintainer should +2 their own patch immediately either, that suggests<br>
> no further reviews are needed.<br>
><br>
> Niels</p>
<p dir="ltr">After realising this we configured Jenkins to be triggered either on code review +2 or a verified +1. Even if it is the maintainer who sent the patch, he/she can certainly give a +1 verified. </p>
<p dir="ltr">There seems to be some problem with both these type of events though. I tried various combinations yesterday, yet the events don't reach Jenkins. I am afraid we will have to go back to patch set triggers until we update our plugins. </p>