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