Just to be clear I didn't simply describe what the HBase community is doing in this regard but also submitted those ideas for consideration here. I could make the same dismissive statement about your pointer to the Ignite lists.
> On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <[email protected]> wrote: > > What Andrew describes is a good step forward CTR process and I am sure HBase > community will find a process that works for them the best. I still think CTR > and yet another step further. I believe if a person has commit-bit it is, > essentially, means that his judgement is trusted and he knows what's good to > the project and won't hurt the code intentionally. Mistakes will be happening > under either of the processes. But the trust in your community fellows goes > long way, I think. > > We had this discussion on Ignite dev@ list just about a month ago [1]. And all > sorts of arguments were expressed there, and I'd encourage everyone to spend > a little bit of time reviewing it. The great points were made by Brane [2], > [3], and [4]. They aren't that long and esp. [3] is very deep, in my option. > > Considering that I really agree with what Brane and myself (doug ;) have said > on that thread I won't repeat myself here, but just ask to look at the last > three emails from below. > > BTW, Ignite is on the CTR process for about a month now - nothing morbid had > happened to it. And the rate of the development in this project is pretty > high, actually. > > Thanks, > Cos > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html > > [2] > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html > [3] > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html > [4] > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html > >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote: >> 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. >>>>
