On Sat, Nov 28, 2015 at 01:15AM, moon soo Lee wrote: > Thanks for starting the thread. I was keep an eye on discussion about > CTR/RTC on the general@incubator. > > I saw people think RTC means lack of trust in that discussion. To me that > is complete nonsense. I can say, RTC trust others more, trust reviewer. So > I don't agree the "reason" CTR over RTC in the discussion on > general@incubator.
CTR doesn't mandate an absence of reviews. The 'R' is still there. And same way is before anyone is welcome to make the review for the committed code. > Importantly, Zeppelin project used to count not only review from committer > but also review from any contributor. This kind of consensus sharing among > the community may be lost or weaken when committers start commit in CTR > fashion. I don't see how it is possible. Empirically it isn't ever a case as well. Could you please elaborate how this might happen in your view? > But what I agree is, CTR can be faster than RTC. That can help speed up the > development of Zeppelin and that's what I personally really want and can't > wait. > > So, to me, applying CTR for this reason is more than welcome. But I think > we need some preparation to keep the consensus in the community. It isn't only about speeding up. It is about the maturity and mutual appreciation of my fellow committers, doing 'the right thing'. Using/building coding guidelines is a good idea, as I said elsewhere. And it will definitely help to reduce jitter and noise on the mailing lists. But it is orthogonal to the topic, discussed here. What I encourage you to do, is to run a trial for CTR and see how this works. If something is badly broken - it always can be reverted. That's why we are using VCS for the software development. Cos > I think building set of guidelines for each components (GUI / Core / > Interpreter / Notebook Storage / etc) would help. Contribution guide that > we're discussing on mailing list [1] and "Zeppelin UI design principle" [2] > could be example, what guidelines trying to do. Community can discuss and > create/change guidelines. > > Once they're settled then I think there will be no big problem applying CTR > in Zeppelin project. And that means some type of discussion about the code > is going to be moved from individual pullrequest to guidelines. Which is > indirect but more scalable way. > > Best, > moon > > [1] http://s.apache.org/ma4 > [2] > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328042 > > > On Sat, Nov 28, 2015 at 8:05 AM Konstantin Boudnik <[email protected]> wrote: > > > Guys, > > > > as you might have seen on the general@incubator list, there's a lengthy > > discussion about benefits of Commit-Then-Review (CTR) development model > > over > > Review-Then-Commit (RTC) one. > > > > As the project is getting more mature, I would like to start the > > conversation > > on what the community think about this sort of thing. If anyone isn't clear > > about the topic - please chime in and I would be happy to go into as much > > details as needed. In the meanwhile, here a coupe of links that might help > > > > Apache Ignite CTR vs RTC discussion (Ignite is CTR project) > > http://s.apache.org/wPA > > Apache Bigtop CTR vs RTC long thread (Bigtop is a CTR project as well) > > http://is.gd/TgBovX > > > > Regards, > > Cos > >
signature.asc
Description: Digital signature
