I think that's reasonable. Also relevant is this old conversation we had about "urgent" updates: https://lists.apache.org/thread.html/3e4b00037eecab92318a510df38c56da5ecddbbe98407d239995bac7@<dev.fluo.apache.org>
On Wed, Sep 4, 2019 at 2:05 PM Keith Turner <ke...@deenlo.com> wrote: > I am in favor of option #1. I think a model of RTC with a time limit > would be nice, where it if there is not activity in 72hrs that its > approved by lazy consensus. > > On Wed, Aug 28, 2019 at 11:54 PM Christopher <ctubb...@apache.org> wrote: > > > > 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 > > https://www.apache.org/foundation/glossary.html#ConsensusApproval > > 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.) > > > > Thoughts? > > > > Christopher >
