On Wed, Jul 29, 2015 at 7:26 PM, Andrew Purtell <[email protected]> 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)
>
