[Gluster-devel] Gerrit review, submit type and Jenkins testing
Kaushal M
kshlmster at gmail.com
Fri Jan 8 06:58:08 UTC 2016
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.
>
>>
>> Too many developers use the upstream infra as a test cluster and it is
>> *not*.
>> It is a verification mechanism for maintainers to ensure that the patch does
>> not cause regression.
>> It is required that all developers run full regression on their machines
>> before asking for reviews.
>> Reviewers should review the patch only when the developer has given a +1
>> verified on the patch.
>> Again, I will work with Kaushal to get this done.
>>
>> P.S: Stop using the "universal" jenkins account to trigger jenkins build if
>> you are not a maintainer.
>> If you are a maintainer and don't have your own jenkins account then get one
>> soon!
>
> I think I'll go ahead and remove this account.
This is done now.
>
>>
>> Thanks,
>> Raghavendra Talur
>>
More information about the Gluster-devel
mailing list