incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: RTC vs CTR (was: Concerning Sentry...)
Date Wed, 18 Nov 2015 12:35:39 GMT
Le 18/11/15 11:31, Stephen Connolly a écrit :
> I believe the issue here is that with CTR it is very easy to miss the 72h
> lazy consensus voting (with an assumed +1 absence any votes cast) that most
> CTR projects operate under... and thus it can also be very easy to miss the
> fact that there are reviews going on (and I am being generous here, I
> suspect that a lot of CTR commits are only reviewed within the 72h by a
> blind man on a galloping horse)

I'm not sure why you are correlating commit reviews and a 72h vote...
They are two really different things.

>
> If the PMC is doing its duty, then when release time comes around, if they
> have not been tracking the commits, then they should not be providing a
> binding +1 for the release until they have reviewed the commit delta from
> the last release *at least from the point of view of ASL compliance*.
No. There is nothing that says such a thing. It would be very good if
every PMC member casting a vote were reviewing all the commits since the
last release, but this is unlikely to happen, and it's not even
required. And unless you point us to the so called ASL compliance, I
think this is your own interpretation of the PMC member that you are
pulling here.
>
> So if we look at a well established CTR project such as Maven, you do not
> see many comments on individual commits... from this you might be forgiven
> if you concluded that there is no review going on... and thus infer that
> CTR is really C. I cannot speak for the entire Maven PMC but I can assure
> you that I reviewed each and every commit in the delta between the 3.3.3
> release and the 3.3.9 release from both a technical perspective and the
> legal umbrella perspective (does that mean I spotted every bug, nope... no
> code review can catch every bug... and it took us 6 goes to get the release
> out... but there was review)
That's good for Maven. But that does not mean any other project should
do so.

Look, this is where we *trust* other committers - and this is the reason
we voted them in, btw - : they *know* they should not break the ASF
rules (IP, etc) plus they *know* they should not break the trust the
community has put in them.

In 10 years, I have very rarely seen such things happening - and most of
the time it was a mistake -. I saw someone pushing some revamped Sun
code (and signaled so to the project), vote -1 on one commit (not sure I
should be proud of that veto, btw) and asked for some better code to be
pushed a few times, but more as a discussion than as a formal request.
Otherwise, did I saw some commits that needed some fixe because they
were breaking the build ? You bet ! (and I plaid guilty as charged too).
Bottom line, trusting my co-workers was easy : they are all my pairs,
and I don't feel like I'm any superior in any way, so I was expecting
their code to be at least as good as mine. Who would I be if I was to
check their daily commits and not asking them to review mine otherwise ?

And the best of it : it simply works. With flying colors. We have a
bunch of tests that avoid many errors to be introduced into the code,
and we can release fast enough so that our users can actually be real
users, and provide us with feedbacks. There is nothing better than users
feedbacks : not only they see what's wrong in our products, but they
also use it ways we haven't thought about, discovering new problems we
totally missed. That's the key : release often means get quick feedbacks.

But there is more : asking people who are volunteers to review what
others are pushing would introduce a latency that would certainly kill
the project.

Now I can see how people being paid by a company might *want* such
reviews to be done (regardless of the mode, CTR or RTC), and I feel that
as a bias toward a control by a few companies, excluding de facto those
who don't have time to work on the project but what they squeeze out of
a day job, familly, and sleep... And I saw that frequently in *many*
projects ! Sounds like a hidden agenda, isn't it ?  That would may be
pushing the thing a bit too far, but I suspect that in some case, yes,
that was exactly that. This is *NOT* The Apache Way...



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message