hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: [DISCUSSION] Switching from RTC to CTR
Date Fri, 31 Jul 2015 23:03:08 GMT
​If you go to the end of the thread there's a much less sweeping proposal
with a specific and carefully considered reason.​

On Fri, Jul 31, 2015 at 4:02 PM, Stack <stack@duboce.net> wrote:

> Hit the send button by mistake. Added in finishing paragraph on below.
>
> On Sat, Aug 1, 2015 at 12:47 AM, Stack <stack@duboce.net> wrote:
>
> > 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
> >
> >
> Scratch the above last paragraph.
>
> My understanding is that we do RTC, putting aside for now any consideration
> of the quality of the reviews, because it is one of a few (poor) means we
> deploy to guard against regression and to prevent surprise.
>
> Thats enough for now,
> St.Ack
>
>
>
> >
> >
> >
> >
> >
> >
> >> 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)
> >>
> >
> >
>



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