incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Impala commit policy
Date Thu, 03 Dec 2015 07:04:00 GMT
On Wed, Dec 2, 2015 at 8:50 PM, Julian Hyde <> wrote:

> Thanks, Roman. For the record, I don’t plan to contribute to Impala or
> Kudu, and I don’t like strict commit policies such as RTC. But I wanted to
> stand up for “states' rights”, the right of podlings and projects to
> determine their own processes and cultures.

LOL ... being a Texan, I can certainly get on board with the notion of
states' rights :-P

But I caution: as I said else-thread, we use the Incubation process because
we believe the podling needs to *learn* how we like communities to operate.
Peer respect, inclusivity, open dialog, consensus, etc. By definition, the
podling is unable to make these decisions within the guides and desires of
the Foundation. If we trusted them to do so, then we'd just make them a TLP
and skip incubation.

Josh puts it well:

On Thu, Dec 3, 2015 at 12:26 AM, Josh Elser <> wrote:

> +1 I'm not entirely sold on saying they have no explicitly policy up front
> (I'd be worried about that causing confusion -- the project will operate
> how they're comfortable operating), but I'd definitely want to see _real_
> discussion is had after the podling gets on its feet and grows beyond the
> initial membership.

I'd like to see podlings have enough diversity and independence from the
initial PPMC, to have such a discussion. My fear is that RTC holds back
growing the diversity of opinion, and that status quo will not allow for
moving away from Gerrit.


I will also note that one of the primary reasons explained for RTC is "the
code is too complex to allow for unreviewed changes to be applied". Has
that basis been justified for Impala? Are we talking data loss? Nope. It's
a layer over the data substrate. Synchronization across a cluster? Nah.
Where is the complexity?

In this case, the RTC seems to stem from the choice of Gerrit, rather than
some innate complexity.

I *do* note that possibly committers could choose to commit directly, or
choose to use Gerrit when they are unsure. Will the (P)PMC allow those
direct commits? Or mandate Gerrit for every commit?


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message