I think Zeppelin community has been very pro-active on handling patch requests and both strict RTC vs CTR as in general list discussions could be mediated by something in between.
For example, patches or CR that changes existing behavior should be reviewed to make sure not breaking anything and have good unit tests, but new features that have design documents could probably committed directly once the design has been reviewed. - Henry On Sat, Nov 28, 2015 at 1:15 AM, Eran Witkon <[email protected] <javascript:;>> wrote: > My 2 cents here... > I know that I got good and productive feedback through the review process > and I am happy it was included before it was committed. > I agree that that the review does not need to be done by the PMC members > but should be handled on the DEV list. > I am sure that for every PR which has a review process in the DEV list and > enough +1 voting for it it will be committed even if none of the PMC tested > it. > I this only if and when we see PR with enough +1 which are not committed > then we can think of speeding it up with RTC or adding more committers. > So bottom line is +1 for RTC > Eran > > On Sat, Nov 28, 2015 at 7:55 AM Konstantin Boudnik <[email protected] <javascript:;>> wrote: > >> 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 >>
