On Fri, Jan 08, 2016 at 12:46:09PM +0530, Raghavendra Talur wrote: > On Fri, Jan 8, 2016 at 12:28 PM, Kaushal M <kshlms...@gmail.com> wrote: > > > On Fri, Jan 8, 2016 at 12:10 PM, Kaushal M <kshlms...@gmail.com> wrote: > > > On Fri, Jan 8, 2016 at 12:03 PM, Raghavendra Talur <rta...@redhat.com> > > wrote: > > >> Top posting, this is a very old thread. > > >> > > >> Keeping in view the recent NetBSD problems and the number of bugs > > creeping > > >> in, I suggest we do these things right now: > > >> > > >> a. Change the gerrit merge type to fast forward only. > > >> As explained below in the thread, with our current setup even if both > > PatchA > > >> and PatchB pass regression separately when both are merged it is > > possible > > >> that a functional bug creeps in. > > >> This is the only solution to prevent that from happening. > > >> I will work with Kaushal to get this done. > > >> > > >> b. In Jenkins, remove gerrit trigger and make it a manual operation > > > > > > Making it manual might be too much work for maintainers. I suggest (as > > > I've suggested before) we make regressions trigger when a change has > > > been reviewed +2 by a maintainer. > > > > > > > Makes sense. I have disabled it completely for now and lets keep it that > way till > developers realize it(a day should be enough). We will change this trigger > to on Code Review +2 by tomorrow.
Aaaaah! And I have been wondering why patches don't get verified anymore :-/ An email to the maintainers list as a heads up would have been welcome. How would we handle patches that get sent by maintainers? Most developers that do code reviews will only +1 those changes. Those will never get automatically regression tested then. I dont think a maintainer should +2 their own patch immediately either, that suggests no further reviews are needed. Niels
signature.asc
Description: PGP signature
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
