On Sat, Nov 28, 2015 at 10:47 AM Konstantin Boudnik <c...@apache.org> wrote:
> 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. > > Thanks for explanation about 'R' in CTR. But my point was that I believe 'R' in RTC does not comes because of lack of trust. my point wasn't about 'R' is missing in CTR. > > 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? > > Let me share some history about Zeppelin project, It was developed in CTR way in the beginning. and it continued until sometime around Zeppelin enters Apache incubation. Then somehow naturally switched to RTC. We didn't explicitly discussed about CTR/RTC change at that time, so i can't say the exact reason. But i can guess the reason. Users were growing rapidly at that time and most of them build Zeppelin from master branch. And we didn't wanted to break the code and become extremely careful to merge pullrequest without review. That's how RTC landed into Zeppelin, i think. After review becomes so important, we started respect any review from not only committers but also contributors (non-committers). That continued until now. And now I see the only difference between committer and contributor is that committer can initiate lazy consensus. So participating review becomes one of the major way influencing the project. But obviously, by their nature, 'R' in CTR is less encouraging compare to RTC. Again I'm not saying 'R' is not in CTR. If someone say 'R' in CTR is more encouraging than 'R' in RTC, then i also can say, RTC is faster then CTR. I mean less encouraging is 'compare to' RTC. And while committers goes with CTR, contributors will remain RTC. Because of this nature of CTR / RTC differences, there's chances to reduce influences from contributor (non-committer) in this project and my worry here was about this. If you can share some experience from Bigtop, especially about those who is not a committer, after changing RTC -> CTR, that would be really interesting and helpful. > > 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'. > > Even though I agree and I want to go CTR, I don't believe community have CTR is more mature than RTC. vise versa. 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 there're still many users building Zeppelin from master branch. We at least need to guide user to use release branch instead of master. Of course more frequent releases will help. Then it'll be much more pleasant to try CTR and break something. Thanks, moon > > > 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 <c...@apache.org> > 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 > > > >
