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:45:51 GMT
On Fri, Jul 31, 2015 at 4:02 PM, Stack <stack@duboce.net> wrote:

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


You bring up a great point I go back and forth on myself: committers
produce work on a spectrum of quality. Nothing about having a CTR commit
regime says there isn't also have a culture of voluntary code review. And a
nightly suite of regression tests. I trust that people will (mostly) do the
right thing, having strict rules does get down to mistrust on some level. I
have an opinion on the quality of my own engineering. I have opinions on
the typical quality of engineering I can expect from all of the active
committers too. I'm going to keep them to myself. We collectively voted to
give committers to commit bit, therefore you are all my peers and vice
versa. What I trust less is the largess of sponsored development. I see the
available bandwidth for review here wax and wane. I can tell when the
vendor based devs are off working on an internal thing. Likewise when
they're working on something as a team I see plentiful resources for the
reviews of that work, but not necessarily for the other outstanding stuff.
Furthermore, some day the product roadmaps will change and those devs may
go away. That is all perfectly fine and expected. However process that
expects we've always got plenty of people around with bandwidth for review
should be viewed suspiciously in that light. A way to avoid that sort of
risk is to say as PMC to every committer: you have been given the commit
bit so you can get shit done, go do what need to be done but remember
<insert consensus expectations on good behavior>. And, as PMC, supervise.
Finally, switching from today's process to something else in no way
precludes switching back if there is a problem in practice with it.


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