If you read the clauses literally there's no conflict - not all committers that
+1 the change need to review the work. It just means that two committers have
indicated they are comfortable with the patch being merged. One of the +1s
could be based on another pre-existing review and trust in both the
contributor's and reviewer's knowledge of the area; and/or by skimming the
patch. Though they should make it clear that they did not review the patch
when +1ing, so there's no ambiguity.
Perhaps we should elaborate on the document to avoid this confusion, as this
has come up multiple times.
On 22/06/2020, 02:56, "Joshua McKenzie" <jmcken...@apache.org> wrote:
The way I've heard it articulated (and makes sense to me) is that a 2nd
committer skimming a contribution to make sure everything looks reasonable
should be sufficient. It's a touch more rigor than we do now (1 contrib + 1
committer) without slowing things down too much. If we can develop a
healthy relationship with git revert on the project as well, this model
should further be de-risked.
Also, on my personal docket is for us to discuss how one becomes a
committer and charting that course in the near future, so hopefully we'll
see our committer pool expand in diversity and count to make this less of a
burden.
On Sun, Jun 21, 2020 at 7:32 PM Joseph Lynch <joe.e.ly...@gmail.com> wrote:
> +1 (nb).
>
> Thank you Josh for advocating for these changes!
>
> I am curious about how Code Contribution Guideline #2 reading "Code
> modifications must have been reviewed by at least one other
> contributor" and Guideline #3 reading "Code modifications require two
> +1 committer votes (can be author + reviewer)" will work in practice.
> Specifically, if a contributor submits a ticket reporting a bug with a
> patch attached and then it is reviewed by a committer and committed
> that would appear sufficient under Code Contribution Guideline #2 but
> insufficient under Code Contribution Guideline #3? I'm sorry if this
> was discussed before I just want to make sure going forward I properly
> follow the to be adopted guidelines.
>
> Thanks again!
> -Joey
>
>
> On Sun, Jun 21, 2020 at 8:34 AM Jon Haddad <j...@jonhaddad.com> wrote:
> >
> > +1 binding
> >
> > On Sat, Jun 20, 2020, 11:24 AM Jordan West <jorda...@gmail.com> wrote:
> >
> > > +1 (nb)
> > >
> > > On Sat, Jun 20, 2020 at 11:13 AM Jonathan Ellis <jbel...@gmail.com>
> wrote:
> > >
> > > > +1
> > > >
> > > > On Sat, Jun 20, 2020 at 10:12 AM Joshua McKenzie <
> jmcken...@apache.org>
> > > > wrote:
> > > >
> > > > > Link to doc:
> > > > >
> > > > >
> > > >
> > >
>
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> > > > >
> > > > > Change since previous cancelled vote:
> > > > > "A simple majority of this electorate becomes the low-watermark
for
> > > votes
> > > > > in favour necessary to pass a motion, with new PMC members added
> to the
> > > > > calculation."
> > > > >
> > > > > This previously read "super majority". We have lowered the low
> water
> > > mark
> > > > > to "simple majority" to balance strong consensus against risk of
> stall
> > > > due
> > > > > to low participation.
> > > > >
> > > > >
> > > > > - Vote will run through 6/24/20
> > > > > - pmc votes considered binding
> > > > > - simple majority of binding participants passes the vote
> > > > > - committer and community votes considered advisory
> > > > >
> > > > > Lastly, I propose we take the count of pmc votes in this thread as
> our
> > > > > initial roll call count for electorate numbers and low watermark
> > > > > calculation on subsequent votes.
> > > > >
> > > > > Thanks again everyone (and specifically Benedict and Jon) for the
> time
> > > > and
> > > > > collaboration on this.
> > > > >
> > > > > ~Josh
> > > > >
> > > >
> > > >
> > > > --
> > > > Jonathan Ellis
> > > > co-founder, http://www.datastax.com
> > > > @spyced
> > > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
