[vtk-developers] Avoiding MR stagnation (was: rules proposal drop "+1")

Will Schroeder will.schroeder at kitware.com
Thu Jul 7 13:38:45 EDT 2016


:-) okay then in order to cross the road, I'll insist more strongly on good
tests and documentation

On Thu, Jul 7, 2016 at 1:27 PM, Berk Geveci <berk.geveci at kitware.com> wrote:

> > Maybe it's because I'm a chicken
>
> +1
>
> On Thu, Jul 7, 2016 at 10:10 AM, Will Schroeder <
> will.schroeder at kitware.com> wrote:
>
>> It's a time problem: I see chunks of code which at a superficial level
>> seem fine and I'm willing to give it a +1. The problem with a +2 is that
>> issuing such a score has implications that I've jumped into the code at a
>> deep level and can vouch for it. This can occasionally mean hours or days
>> of work hence the delay. Maybe it's because I'm a chicken and should have
>> faith (or otherwise ensure) that there is enough testing to proof it out,
>> but I feel reluctant in some cases to give a +2 without enough due
>> diligence which takes time I often don't have. Besides more testing, one
>> thing that might help would be more "documentation" providing me with the
>> confidence that important issues have been considered and accounted for.....
>>
>> Best,
>> W
>>
>>
>> On Thu, Jul 7, 2016 at 9:56 AM, Brad King <brad.king at kitware.com> wrote:
>>
>>> On 07/07/2016 08:56 AM, David E DeMarle wrote:
>>> > In either case both authors and reviewers are responsible for
>>> > watching the dashboards and addressing issues that come up afterward.
>>>
>>> This is the real reason people are hesitant to +2.  If we strengthen
>>> the meaning of +1 then people will just say "LGTM" or something else
>>> to "approve" without taking responsibility.  Posting +1 is a common
>>> convention for voting and should not be given stronger meaning.
>>>
>>> The real problem we'd like to address is stagnation of MRs that
>>> are ready but not merged.  The syntax for approving is not very
>>> important.  We should identify reasons MRs stagnate and address
>>> them directly:
>>>
>>> * It may be a governance problem.  No one has responsibility
>>>   to ensure everything that is ready gets merged.
>>>
>>> * It may be a workflow problem, like waiting for buildbot results
>>>   to approve and then forgetting.  The new workflow:buildbots
>>>   label may help here.
>>>
>>> -Brad
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Search the list archives at:
>>> http://markmail.org/search/?q=vtk-developers
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>>
>>>
>>
>>
>> --
>> William J. Schroeder, PhD
>> Kitware, Inc. - Building the World's Technical Computing Software
>> 28 Corporate Drive
>> Clifton Park, NY 12065
>> will.schroeder at kitware.com
>> http://www.kitware.com
>> (518) 881-4902
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtk-developers
>>
>>
>>
>


-- 
William J. Schroeder, PhD
Kitware, Inc. - Building the World's Technical Computing Software
28 Corporate Drive
Clifton Park, NY 12065
will.schroeder at kitware.com
http://www.kitware.com
(518) 881-4902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160707/705988ca/attachment.html>


More information about the vtk-developers mailing list