Re: Commit / Code Review Policy

[Jason Gerlowski <ge...@gmail.com>]

> and now its turned around as if its consensus everywhere

David didn't say anything about consensus everywhere.  He mentioned
pretty clearly that the agreement was only "in attendance", and that
this thread was a precursor for putting together a proposal to test
the waters further.  That all seems pretty in line with the Apache
process for feeling out/testing/etc. consensus, though maybe there's a
nuance I'm missing?

Jason

On Sat, Nov 30, 2019 at 3:27 PM Shawn Heisey <ap...@elyograg.org> wrote:
>
> On 11/30/2019 7:39 AM, Robert Muir wrote:
> > -1 ... you even went so far as to discourage lucene committers from
> > attending that meeting, and now its turned around as if its consensus
> > everywhere and should be applied to lucene too?
> >
> > I don't think changing things to review-then-commit will help.
>
> I did attend the meeting, and I think committers who concentrate on
> Lucene should not be discouraged from attending any similar future
> meetings.  Discussions in a meeting about Solr are not very likely to
> dive down that far into the inner workings, but even if they don't, some
> Lucene people might find the the talk about Solr to be interesting, and
> having their perspective available would not be a bad thing.
>
> I'm very wary of making an official change to review-then-commit.  I
> fully support the ideas that went into the proposal, but I think making
> it mandatory for all commits is going to really slow things down and
> cause some problems.  It's not the way most Apache projects work, and it
> makes it a LOT harder to do quick sanity edits like fixing spelling errors.
>
> As much as I really like the idea of more frequent reviews, I think that
> review requirements should be informal.
>
> Most of the time a committer will know whether the changes they are
> working on fall into a "major" or "minor" category.  When it's leaning
> more towards major, I think most of us will agree that a few extra
> eyeballs looking for gotchas is a really good idea.  TLDR note:  The
> number of lines in a change is sometimes NOT an indicator of how major
> the change is.
>
> I certainly want to seek a "looks good to me" on changes I make which
> have any significant impact.  For some of the ideas I have, if those
> ever reach the implementation phase, I think I'd want even more
> assurance that I'm not doing it wrong.  I can pledge that I will seek
> review for non-trivial changes.  I wonder if there is wording we can add
> to any official project rulebook to make such a thing mandatory, without
> a full switch.
>
> I think that a full switch to review-then-commit (RTC) would be the
> wrong thing to do.  I think it would lead to a lot of dissent within the
> project, encouraging rivalries and cliques within the project.
>
> If RTC is preferred by a significant majority, I will work within that
> paradigm ... but I think that it would be a short-lived experiment and
> we would be back to CTR pretty quickly.
>
> Is it possible to vote -0.5 instead of -1?  I don't think it is.
>
> Thanks,
> Shawn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org