I made this argument over on the dev@hbase list: If the community considers quality a priority (and we do, right? (Smile)) then we should have a strong code review ethic whether technically bound to have one (RTC) or not (CTR).
I started a discussion to move over to CTR on HBase because some components or niche concerns don't draw prompt reviews, slowing down the contributor/committer because their next steps depend on the current patch. We had this discussion on our dev@ list. You can find it in the public archives if curious. However I was mostly convinced we have sufficient tools without CTR so that's not necessary, eg: - Any committer can check anything into a dev branch (non release branch) without review; review comes later at the branch merge vote. Haven't checked if we have a branch merge policy. We can always add one. - Small fixes or test only changes are given leeway to the committer's discretion. Try to wait long enough if a volunteer wants to show up and do a review. - We have an informal consensus practice where as long as the change doesn't have major impact (again, committer discretion) then after an issue sits a day or two one might post "going to commit this later today unless objection" - and, if no objection, this is a "lazy review" and commit. For your consideration. > On Sep 14, 2015, at 7:33 AM, RJ Nowling <[email protected]> wrote: > > I don't want to derail this decision if CTR has general approval. I would > be happy with a clear checklist document that we can all agree to follow > before commits. > > On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <[email protected]> > wrote: > >> i think we moved this discussion here >> https://issues.apache.org/jira/browse/BIGTOP-1249 >> >> The goal is definetely to get automated reviews. >> >> we hacked around successfully with some prototypes but never productionized >> them. >>
