You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@zeppelin.apache.org by Konstantin Boudnik <co...@apache.org> on 2015/11/28 00:05:28 UTC

Trying CTR for the project

Guys,

as you might have seen on the general@incubator list, there's a lengthy
discussion about benefits of Commit-Then-Review (CTR) development model over
Review-Then-Commit (RTC) one.

As the project is getting more mature, I would like to start the conversation
on what the community think about this sort of thing. If anyone isn't clear
about the topic - please chime in and I would be happy to go into as much
details as needed. In the meanwhile, here a coupe of links that might help

    Apache Ignite CTR vs RTC discussion  (Ignite is CTR project)
      http://s.apache.org/wPA
    Apache Bigtop CTR vs RTC long thread (Bigtop is a CTR project as well)
      http://is.gd/TgBovX

Regards,
  Cos

Trying CTR for the project

Posted by Henry Saputra <he...@gmail.com>.

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 <eranwitkon@gmail.com
<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 <cos@apache.org
<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
>>

Re: Trying CTR for the project

Posted by moon soo Lee <mo...@apache.org>.

I think we should at least explicitly document current process somewhere
first.

The place would be
https://github.com/apache/incubator-zeppelin/blob/master/CONTRIBUTING.md
or
https://github.com/apache/incubator-zeppelin/blob/master/docs/development/howtocontribute.md
.

Then it'll help committer and contributor understand the process. And
improving the process (eg. this discussion) will be much easier and
smoother.

Thanks,
moon

On Tue, Dec 1, 2015 at 10:10 AM Alexander Bezzubov <bz...@apache.org> wrote:

> 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 <he...@gmail.com> wrote:
>
> > Sounds good to me, and thanks again for bringing this to discussions.
> >
> > On Sunday, November 29, 2015, Konstantin Boudnik <co...@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 <cos@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 <
> cos@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
> > > > > > >
> > > > >
> > >
> >
>

Re: Trying CTR for the project

Posted by Alexander Bezzubov <bz...@apache.org>.

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 <he...@gmail.com> wrote:

> Sounds good to me, and thanks again for bringing this to discussions.
>
> On Sunday, November 29, 2015, Konstantin Boudnik <co...@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 <cos@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 <cos@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
> > > > > >
> > > >
> >
>

Re: Trying CTR for the project

Posted by Corneau Damien <co...@gmail.com>.

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 <he...@gmail.com>
wrote:

> Sounds good to me, and thanks again for bringing this to discussions.
>
> On Sunday, November 29, 2015, Konstantin Boudnik <co...@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 <cos@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 <cos@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
> > > > > >
> > > >
> >
>