[Gluster-devel] Proposed change in Gerrit workflow

[Deepak C Shetty]

On 09/26/2012 11:41 AM, Vijay Bellur wrote:
> On 09/26/2012 10:34 AM, Deepak C Shetty wrote:
>> On 09/25/2012 04:13 PM, Vijay Bellur wrote:
>>> Hi All,
>>>
>>> We intend to bring the following change in our gerrit based workflow:
>>>
>>> - Introduce +2 and -2 for Verified in Gerrit
>>> - +2 for Verified to be necessary for merging a patch
>>>
>>> The intent of this proposed change is to get additional test coverage
>>> and reduce the number of regressions that can sneak by. Jenkins would
>>> continue to provide +1s for all submitted changes that pass basic
>>> smoke tests. An additional +2 would be necessary from somebody who
>>> tests the patch. Providing a +2 for Verified would be semantically
>>> similar to adding a Tested-by: tag.
>> I have a basic doubt here.. How is +2 verified different than +1
>> verified, which is currently provided by either the author or someone
>> else or both. I assume that the Jenkins +1 verified is not the only
>> thing that is seen by the maintainer before merging the patch, he/she
>> should be looking at +1 verified from the author or someother person and
>> take the decision accordingly during merge.
>>
>
> That is not the work flow model we follow currently. Authors and 
> testers do not provide +1 verified usually and patches do get accepted 
> with +1 verified from Jenkins. The necessary condition today for 
> accepting a patch is +2 Code Review and +1 Verified. With the proposed 
> change it would become +2 Code Review and +2 Verified. This change 
> would mean that we will not merge patches even accidentally when it 
> has been acked by Jenkins only.

Hmm, that would be different than the way other projects ( eg. vdsm, 
ovirt) use +1 verified. Wouldn't that cause confusion for people coming 
from different gerrit project ?

What happens if the user / author / tester verifying the patch gives a 
+1 ( thinking +2 is for priviledged/maintainer ) , the workflow will 
still break.