On Sun, Nov 29, 2015 at 09:20AM, Henry Saputra wrote: > Cos, > > Let's allow the community think about it.
Sure thing. The reason I was replying to these emails is because of the falsehood graduation "requirements" these guys were inventing on the go. That had to be clarified. > You have expressed your points about CTR vs RTC. > Both have merits in their own way and we have to see which one fits with > Zeppelin community. > > - Henry > > On Saturday, November 28, 2015, Konstantin Boudnik <[email protected]> wrote: > > > On Sat, Nov 28, 2015 at 09:15AM, Eran Witkon 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. > > > > This is a non sequitur. CTR doesn't prevent you or anyone else from getting > > reviews. I suggest we stop milking this argument, because it is simply > > false. > > > > > I agree that that the review does not need to be done by the PMC members > > > but should be handled on the DEV list. > > > > Again, this is a some sort of misconception about an incubator project > > (which > > doesn't have a PMC, but a PPMC - which is a bike with training wheels to > > teach > > people what PMC will be exposed to in the future). As explained in [1] > > > > Let's take a short detour.... > > "The Podling Project Management Committee (PPMC) helps a Podling learn how > > to > > govern itself. It works like a PMC but reports to the Incubator PMC > > instead of > > to the ASF Board. Initially, it is composed of the Podling's mentors and > > initial committers. The PPMC is directly responsible for the oversight of > > the > > podling and it also decides who to add as a PPMC member." > > > > (P)PMC isn't a super-natural authority that rules over the technical > > aspects > > of the project, but rather a project governance mechanism. PMC has a very > > clear set of responsibilities explained in [2]. In short they are > > > > Comply With Legal Affairs Policies > > Comply With Brand Management Policies > > Responsibly Report Misuses Of Apache Brands > > Conduct Project Business On Mailing Lists > > > > In other words, PMC-hat is irrelevant in code reviews or making technical > > decision, until it comes to release votes for which PMC is responsible. > > > > End of detour. > > > > > 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. > > > > Unless this is a unfortunate choice of words, it is not how it works. No > > voting is needed for a code change to be committed. Apache doesn't use > > voting > > for the mundane fixes and patched. However, a vote can be colled on a code > > modification as explained in [3] > > > > > 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 > > > > What number of "+1"s is _enough_ for a patch to get committed? Obviously, > > every project can make it as high as needed to satisfy their liking. Most > > RTC > > projects say "at for a patch to get committed least one +1". But I can > > imagine projects that would require 5 +1s (or any other ludicrous number) > > to > > get a change in. I would also imagine that NOTHING ever will be done in > > such > > > > "a PR with enough +1 which are not committed" is a problem that won't be > > solved by either CTR or RTC or whatever. This would be most likely the > > issue > > where committers aren't willing to commit stuff because they don't won't to > > take responsibility for it, but are fine with reviewing it. As the result > > the > > progress will stall. > > > > Using voting to substitute the consensus building is a false path. Apache > > isn't a democracy, ruled by majority preferences. If there is a majority - > > there's always a minority. Once such split is allowed to happen the > > community > > will be screwed sooner or later, as the split will lead to internal > > tensions, > > conflicts and drama. Do not go there... > > > > [1] https://incubator.apache.org/guides/ppmc.html > > [2] https://www.apache.org/dev/pmc.html > > [3] https://www.apache.org/foundation/voting.html > > > > Cos > > > > > 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 > > > > > >
signature.asc
Description: Digital signature
