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

Berk Geveci berk.geveci at kitware.com
Thu Jul 7 13:41:02 EDT 2016


If there is new functionality, I do not approve without testing &
documentation. If it's a bug fix, I may ask if there is a test that would
fail without the fix.

On Thu, Jul 7, 2016 at 1:38 PM, Will Schroeder <will.schroeder at kitware.com>
wrote:

> :-) 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/ac358c1c/attachment.html>


More information about the vtk-developers mailing list