Sounds good to me, and thanks again for bringing this to discussions. On Sunday, November 29, 2015, Konstantin Boudnik <c...@apache.org> wrote:
> 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 <c...@apache.org > <javascript:;>> 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 <c...@apache.org > <javascript:;> > > > <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 > > > > > > > > >
