Hit the send button by mistake. Added in finishing paragraph on below. On Sat, Aug 1, 2015 at 12:47 AM, Stack <[email protected]> wrote:
> 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 > > 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) >> > >
