On 17/11/2015 08:20, "Greg Stein" <gst...@gmail.com> wrote:
>On Tue, Nov 17, 2015 at 1:53 AM, Bertrand Delacretaz ><bdelacre...@apache.org >> wrote: > >> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <ted.dunn...@gmail.com> >> wrote: >> > ...RTC can be framed as "I don't trust you to do things right"... >> >> Or also "I don't trust myself 100% to do things right here and would >> like systematic reviews of my commits". >> > >People should be trusted to ask for help/review when necessary. CTR trusts >people to commit changes they feel are right, but it also trusts them to >stop and ask for a preliminary review when they feel/know they're deep >into >the tricky code. > >RTC never trusts people with the easy changes. It believes all changes are >equal, assumes all changes are beyond the abilities of individuals, and >all >committers are incapable of self-reflection. That each and every change >must be scrutinized by others for approval. > >Ted's phrase "I trust you to help me make things better" is not unique to >RTC. Both CTR and RTC have that "R" in them for review, to ensure the code >can always be improved. > >If I join a CTR community, then I know that I can go around improving >comments, docstrings, and minor code cleanups. That is a solid >contribution >that every project would love to have. If I join an RTC community, I'm not >trusted to do any of that. There is no other explanation. None of that has >to do with "complexity". It is simply control and exclusion of my >desire/interest to contribute. To keep the mantle of development within a >select set of people who decided to exert this tactic over their codebase. > >-g We're veering dangerously off into religious debate territory here but I think this is a great explanation of the fundamentals of CTR which is personally my preferred model The other aspect of trust in the CTR model that we haven't really mentioned is that in a CTR community you also trust that when you do commit stuff without prior review that others will review it after the fact. On CTR projects I'm involved in myself and others do read through the commits list traffic and can and do flag things for further discussion and review when we feel they need it. So there is a more equal trust relationship, you trust me to commit things without prior review and I trust you to review them afterwards as needed. Additionally you trust me to know when to ask for a prior review. In RTC it seems like an unequal trust relationship, I have to trust you to review my code because you don't trust me to commit it myself. Of course the counterpoint to this argument is that in a RTC community you typically grant commit privileges much sooner and trust people to get reviews whereas in a CTR community you often make new people work via RTC for a while before you trust them enough to grant them commit privileges. It feels like part of the problem is that RTC vs CTR very much blurs the line between a community and a technical decision. Supporters of CTR like myself tend to feel that CTR is ultimately about community I.e. that assuming trust helps build a healthier community. On the other hand the arguments for RTC often seem to come from the standpoint of it being a technical decision e.g. the complexity and committer fallibility arguments already expressed in this thread and seem IMO to boil down to the idea that RTC builds better code. The Apache way is often defined as "community over code" hence when I tend to default to CTR however I don't see RTC as being harmful to community I just feel like it produces a different kind of community. The ASF is a big umbrella and whichever side of the debate a community comes down on there is room for them at the ASF. Probably the key takeaway from this thread should be that we should trust podlings (and TLPs) to have the RTC vs CTR debate within their own communities and allow them to decide what works best for them as a community without an outside body like the Incubator mandating one or the other. Clearly during the Incubation phase mentors and interested parties can and will participate in that debate and outline the various arguments as we've been doing here but the ultimate decision should lie with those in the community. Rob --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
