[Gluster-devel] Gerrit review, submit type and Jenkins testing

Raghavendra Talur rtalur at redhat.com
Tue Jan 12 03:10:34 UTC 2016


On Jan 12, 2016 2:50 AM, "Niels de Vos" <ndevos at redhat.com> wrote:
>
> On Fri, Jan 08, 2016 at 12:46:09PM +0530, Raghavendra Talur wrote:
> > On Fri, Jan 8, 2016 at 12:28 PM, Kaushal M <kshlmster at gmail.com> wrote:
> >
> > > On Fri, Jan 8, 2016 at 12:10 PM, Kaushal M <kshlmster at gmail.com>
wrote:
> > > > On Fri, Jan 8, 2016 at 12:03 PM, Raghavendra Talur <
rtalur at 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

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160112/871109af/attachment.html>


More information about the Gluster-devel mailing list