<div dir="ltr">Who said that the reviewer is responsible for watching the dashboard? And why would changing the meaning of +1 change anything? I regularly +2 MRs and don't follow the dashboard. If some developer starts regularly breaking things, I can always stop reviewing their code.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 7, 2016 at 10:18 AM, Robert Maynard <span dir="ltr"><<a href="mailto:robert.maynard@kitware.com" target="_blank">robert.maynard@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently I believe the issue is that the reviewer is equally at<br>
responsible for watching the dashboard for regressions caused by MR.<br>
<br>
Moving to a simple Yes/No +1/No system where the responsibility for<br>
fixing failures falls to the author would solve the hesitation of<br>
reviewers to give +2.<br>
<div class="HOEnZb"><div class="h5"><br>
On Thu, Jul 7, 2016 at 10:10 AM, Will Schroeder<br>
<<a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a>> wrote:<br>
> It's a time problem: I see chunks of code which at a superficial level seem<br>
> fine and I'm willing to give it a +1. The problem with a +2 is that issuing<br>
> such a score has implications that I've jumped into the code at a deep level<br>
> and can vouch for it. This can occasionally mean hours or days of work hence<br>
> the delay. Maybe it's because I'm a chicken and should have faith (or<br>
> otherwise ensure) that there is enough testing to proof it out, but I feel<br>
> reluctant in some cases to give a +2 without enough due diligence which<br>
> takes time I often don't have. Besides more testing, one thing that might<br>
> help would be more "documentation" providing me with the confidence that<br>
> important issues have been considered and accounted for.....<br>
><br>
> Best,<br>
> W<br>
><br>
><br>
> On Thu, Jul 7, 2016 at 9:56 AM, Brad King <<a href="mailto:brad.king@kitware.com">brad.king@kitware.com</a>> wrote:<br>
>><br>
>> On 07/07/2016 08:56 AM, David E DeMarle wrote:<br>
>> > In either case both authors and reviewers are responsible for<br>
>> > watching the dashboards and addressing issues that come up afterward.<br>
>><br>
>> This is the real reason people are hesitant to +2.  If we strengthen<br>
>> the meaning of +1 then people will just say "LGTM" or something else<br>
>> to "approve" without taking responsibility.  Posting +1 is a common<br>
>> convention for voting and should not be given stronger meaning.<br>
>><br>
>> The real problem we'd like to address is stagnation of MRs that<br>
>> are ready but not merged.  The syntax for approving is not very<br>
>> important.  We should identify reasons MRs stagnate and address<br>
>> them directly:<br>
>><br>
>> * It may be a governance problem.  No one has responsibility<br>
>>   to ensure everything that is ready gets merged.<br>
>><br>
>> * It may be a workflow problem, like waiting for buildbot results<br>
>>   to approve and then forgetting.  The new workflow:buildbots<br>
>>   label may help here.<br>
>><br>
>> -Brad<br>
>><br>
>> _______________________________________________<br>
>> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>><br>
>> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
>><br>
>> Follow this link to subscribe/unsubscribe:<br>
>> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> William J. Schroeder, PhD<br>
> Kitware, Inc. - Building the World's Technical Computing Software<br>
> 28 Corporate Drive<br>
> Clifton Park, NY 12065<br>
> <a href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
> <a href="http://www.kitware.com" rel="noreferrer" target="_blank">http://www.kitware.com</a><br>
> <a href="tel:%28518%29%20881-4902" value="+15188814902">(518) 881-4902</a><br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at<br>
> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
<br>
</div></div></blockquote></div><br></div>