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 <[email protected]> wrote: > 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) > >> > > > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
