Hi guys and thanks for the discussion.
I thought at first that this would be more focus on how the project gets
contributions (The kind of discussion before PR vs PR then
review/discussion),
But after re-reading the definitions, the main aspect is the voting process
when accepting code contributions.
As a Starter, I would say that Zeppelin is more of a CTR type than RTC.
We don't use a voting process to merge code, and here is how our review
process usually goes:
1) A PR is submitted
2) We start looking at it to start discussions if needed, and wait for a
confirmation that its ready to be tested.
3) Anybody can test the PR, but we always have at least one Apache Zeppelin
Committer testing and reviewing it.
4) After an Apache Zeppelin Committer approves the code ('Looks Good',
'+1', 'Let's get to merge'), we would wait for 1 to 2 days for potential
additional reviews.
5) After those 1 or 2 days, we would use a short lazy consensus ('Merging
if there is no more discussions'), and the Code would be merged between
2-4h later (to give a final chance on the Code Review)
I hope this helps understanding how we proceed
On Mon, Nov 30, 2015 at 5:11 AM, 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
> > > > > >
> > > >
> >
>
