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

[Berk Geveci]

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.

On Thu, Jul 7, 2016 at 10:18 AM, Robert Maynard <robert.maynard at kitware.com>
wrote:

> Currently I believe the issue is that the reviewer is equally at
> responsible for watching the dashboard for regressions caused by MR.
>
> Moving to a simple Yes/No +1/No system where the responsibility for
> fixing failures falls to the author would solve the hesitation of
> reviewers to give +2.
>
> 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
> >
> >
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20160707/1ddf7237/attachment.html>