Thanks for the discussion and thoughtful explanation (esp. on graduation requirements), Cos, Henry!
As a community, we are very used to Github pull requests w/ mirroring to the dev@ for the collaboration over code reviews and my preference would be to keep that tooling/workflow (whatever three letters we use). As Damien said - I'm not sure if we are using RTC now, as any committers can merge PRs anytime (with a very fruitful consensus, that there better be at lease one +1 in comments). Presumably people call it RTC I totally agree though, that the project will benefit from faster patch landing time: - if we have guidelines for contribution by component (as some are more critical then others) - if there ware often enough releases, so build from master is not assumed to be latests production-ready code (as it will beak a lot, if we apply merge-first approach) Would be happy to give it a try if there is enough interest in the community, right after we settle immediate priorities of component contribution guidelines, time-based releases and graduation. -- Alexander On Mon, Nov 30, 2015, 05:12 Henry Saputra <[email protected]> wrote: > Sounds good to me, and thanks again for bringing this to discussions. > > On Sunday, November 29, 2015, Konstantin Boudnik <[email protected]> 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 <[email protected] > > <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 <[email protected] > > <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 > > > > > > > > > > > > >
