geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <>
Subject [DISCUSS] require reviews before merging a PR
Date Thu, 30 May 2019 22:51:42 GMT
It seems common for Geode PRs to get merged with only a single green checkmark in GitHub.

According to we should not be merging PRs with
fewer than 3 green checkmarks.

Consensus is a fundamental value in doing things The Apache Way.  A single +1 is not consensus.
 Since we’re currently discussing what it takes to become a committer and what standards
a committer is expected to uphold, it seems like a good time to review this policy.

GitHub can be configured to require N reviews before a commit can be merged.  Should we enable
this feature?

For code-modification votes, +1 votes are in favour of the proposal, but -1 votes are vetos
<> and kill the proposal dead until
all vetoers withdraw their -1 votes.

Unless a vote has been declared as using lazy consensus <>
, three +1 votes are required for a code-modification proposal to pass.

Whole numbers are recommended for this type of vote, as the opinion being expressed is Boolean:
'I approve/do not approve of this change.'

An alternative to voting that is sometimes used to measure the acceptability of something
is the concept of lazy consensus <>.

Lazy consensus is simply an announcement of 'silence gives assent.’ When someone wants to
determine the sense of the community this way, it might do so with a mail message such as:
"The patch below fixes GEODE-12345; if no-one objects within three days, I'll assume lazy
consensus and commit it."

Lazy consensus cannot be used on projects that enforce a review-then-commit <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message