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]> 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
