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. > >>
