See in-lined... On Sat, Nov 28, 2015 at 04:25AM, moon soo Lee wrote: > > > > 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.
Yup, but it has nothing to do with the development model. > 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. Again, I don't see how it is possible. Once the commit is pushed everyone including non-committers are able to look at it. If there's something wrong with it - the issue can be raised same way as before. > 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. Nothing changed for contributors from that stand point of view. Someone needs to review their code before committing. And that's an increased level of trust (sorry, it is overloaded): contributor needs to be guided and perhaps watched. But with a committer you can be sure that if a feedback is desirable the said committer will proactive search for it in the comminity. And if change is trivial - he'll just go ahead and commit the stuff once it is ready. I'd say we haven't seen much of a change in the flow once we switched. People are still asking for review at times. Or just go and commit the stuff once they need to. We still discuss things on JIRAs and dev@ - same as before. > > > 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. There are different criteria of maturity. What I was saying is the committers have to be grown-up for sure. And becoming a committer might be a bit more lengthy process, because you'd want to make sure that this next committer guy will be doing good by the project. Instead of being a drive-by shooter. Cos
signature.asc
Description: Digital signature
