hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: [DISCUSSION] Switching from RTC to CTR
Date Fri, 31 Jul 2015 22:47:02 GMT
On Wed, Jul 29, 2015 at 7:26 PM, Andrew Purtell <apurtell@apache.org> wrote:

> As Greg Stein said on a thread over at general@incubator ("[DISCUSSION]
> Graduate Ignite from the Apache Incubator"):
>
> I always translate RTC as "we don't trust you, so somebody else must
> approve anything you do." To me, that is a lousy basis for creating a
> community. Trust and peer respect should be the basis, which implies CTR.
>
I happen to agree with this sentiment...


The argument is weak. Sentiment based on it is too tenacious a grounding
for changing to CTR, IMO.

As to the argument, Greg's predicate is a subjective 'translation' that RTC
says "we don't trust you". Is there a committer here reading from the same
phrase book such that getting an RM's approval before commit to a release
branch or a review by a fellow contributor as a slight or as a basis for
believing your fellow contributors do not 'trust' your ability to
contribute? If so, please speak up.

Greg's "somebody else" to "approve' also implies antagonism and hierarchy
with a single person or a select group on top gating all changes. These are
attributes many projects have I am sure but this is not such a project,
again IMO. Am I deluded?

Some notes on CTR since this a discussion thread:

+ Any committer can make themselves a CTR space at any time, any where; it
just can't be on a branch from where we intend to cut releases.
+ CTR makes for more code churn (unless committers are inhuman, incapable
of a duh! moment and/or up on all libs, conventions, and implications of
their changes, a tall order in a codebase as broad as ours), because
addressing reviews post-commit requires new commits. More code churn makes
archeology more onerous and tracking change more challenging.
+ This one is a little dodgy but I will throw it out there since this a
discussion thread: CTR purportedly implies 'peer respect' but community
code participation is 'optional' whereas RTC requires you get another
community member to participate in your contribution; hence, RTC forces a
little community around code where CTR has this as optional though
committers bask in 'trust' and 'peer respect'.

Finally, this project has a bunch of committers. Some are better than
others. Becoming a committer does not make you of a sudden a great
engineer. I have a spectrum that ranges from







> and would like to propose switching
> our consensus on commit procedure from RTC to CTR. Concurrently, I would
> like to propose this consensus also include the following:
> - Checkins should pass precommit or the committer should explain on the
> JIRA why precommit failures are in their best judgement not related
> - The PMC should be willing to, ultimately, revoke committership should
> trust in any individual committer be discovered to be misplaced. I would
> expect such a last resort to be exceedingly rare and likely never to happen
> because of course long before that we would be setting correct public
> examples in the first place and respectfully counseling well intentioned
> committers who might stray.
>
> Depending on how the conversation proceeds here I would like to include
> dev@
> in this conversation at the earliest opportunity as well.
>
> Thoughts?
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

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