fluo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject [DISCUSS] Clarifying our R-T-C model
Date Thu, 29 Aug 2019 03:54:39 GMT
Hi Devs,

I noticed that https://fluo.apache.org/how-to-contribute/ links to
https://www.apache.org/foundation/glossary.html#ReviewThenCommit to
describe R-T-C. That link references
which describes a voting procedure that requires 3 +1s and no vetoes.
Voting periods are at least 72 hours at ASF, to allow sufficient time
for feedback. So, we are currently not following the foundation's
definition of review-then-commit.

Rather, what we are doing is something else entirely. Our procedure is
to ensure that at least one committer (other than the author) has
looked over a change and has had the opportunity to examine it and has
no objections. There is no vote, and certainly not a requirement for 3
+1s. Actually, it's not even clear to me that we require the reviewer
to be a committer, although I think I've been assuming it would be.

I think this model is fine, but since it doesn't align to the ASF
definition, there's a few things we can or should do to bring some
clarity to our R-T-C model:

1. We can provide our own definition of review-then-commit,
2. We can start actually following the definition from the Foundation, or
3. We can switch to a commit-then-review model formally, while
informally still encouraging reviews first (obviously, non-committers
have to have stuff reviewed still)

I'm in favor of option #1... but option #3 is appealing to me, because
it's how we operate in Accumulo right now, and I'm starting to get
concerned that we don't have a sufficient number of reviewers active
right now. We're still pretty small in number, and it might be hard to
get reviews at times when people's activity levels fluctuate downward,
which can stall work. (Growing our size is a problem to be addressed,
but that's off-topic for this thread.)



View raw message