RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@apache.org>]

[editing subject since the discussion has veered away from Sentry]

On Mon, Nov 16, 2015 at 7:56 AM, Ralph Goers <ra...@dslextreme.com>
wrote:

> And I have to disagree with you Joe. To me, a mandatory RTC policy says
> “we don’t trust anybody”. Sure, it doesn’t discriminate, but it is also a
> PITA. One project I mentored uses RTC along with ReviewBoard and mandates
> that you cannot commit your own work and every commit must be formally
> reviewed. I have found this process to be so onerous that I have never
> committed any code to the project, even though I really would like to.  I
> find the pace of this project to be fairly slow.  But it seems to fit
> within the corporate culture that most of the committers seem to work in.
>
> OTOH, I am involved in a project that uses CTR but where feature branches
> are frequently created to allow others to review and improve significant
> new work before it is integrated. As a consequence, new features are
> introduced at a much faster pace in this project.
>

I've seen this RTC vs CTR discussion come up a number of times over the
last ~6 years that I've been involved in ASF projects. For every strong
opinion in favor of CTR (like yours) there is a strong opinion in favor of
RTC (like mine).

The quick summary of my viewpoint is:

1) You're right, I don't trust anybody to make code changes to a complex
project with zero oversight. I currently work on a project that I
originally started, and was the only engineer on for a few months. Even
when I make changes to code that I wrote 100% of the module, I get others
to review my work, and you know what? It turns out better for it. Sometimes
they find bugs. Often they find areas where I didn't comment the code well,
design it as well as I could have, or missed potential performance
optimizations.

Coding's hard. Coding on complex projects is even harder. Some projects
aren't complex, and maybe on those a CTR policy makes a lot more sense. But
distributed systems, database storage engines, etc, are pretty hard to get
right, even for the "experts". I'm always glad to have a second pair of
eyes before I introduce a bug that takes down critical infrastructure.

2) Regardless of trust, code review helps build _shared ownership_ of code.
In community projects, without code review, it's easy to end up with "pet
features" or areas of code that only one person understands. When that
person moves on to new employment or new interests, the project is stuck
with a bunch of source code that no one understands how to maintain.
Forcing the original author to get some reviews before committing ensures
that there is a more likely path to project continuity after they move on
to new pastures.

3) Code reviews are a great way for engineers to learn from others in the
community. Earlier in my career, I certainly learned a lot from the
committers on projects like Hadoop and HBase where I "cut my teeth". And
even as a long-time committer on these systems, I still learn new things
from reviewing code written by newer members of the community. Review is
where a lot of the cross-contributor interaction takes place, so it helps
build a cohesive community.

Given #2 and #3, I see RTC as an extension of "community over code". Sure,
it might slow down the introduction of a new feature or fix to have to wait
to get a review from another community member. But, that's just code.
Getting more eyes and hands on the code builds the community.

After writing the above, I started to feel it was familiar and remember a
very similar discussion on hbase-dev last year:
http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_Dz+_rZumfWVyA0tkvXTk4saEie6PWpgs2mxvSbQ8HOpQ@mail.gmail.com%3E
- I'd recommend people go check that one out to see the various viewpoints.

I don't anticipate that the above arguments will convince you, or anyone
else who believes in CTR, to change your mind. But, as mentioned in some
other recent incubator threads, let's not use the incubator as a
battleground for personal opinions. There are successful Apache projects
following all sorts of development models, and the important thing is only
that (a) projects build inclusive communities, and (b) projects follow
proper licensing/release/etc processes for legal reasons.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 16, 2015 at 4:56 PM, Todd Lipcon <to...@cloudera.com> wrote:

> On Mon, Nov 16, 2015 at 2:50 PM, Greg Stein <gs...@gmail.com> wrote:
> > On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <to...@apache.org> wrote:
> > >...
> > > 1) You're right, I don't trust anybody to make code changes to a
> complex
> > > project with zero oversight. I currently work on a project that I
> >
> > I have always found the "complex project" to merely be an excuse for
> > control/no-trust.
> >
> > All software is hard. Your project is no more complex than others.
>
> Having worked on projects in pretty much every layer of the software stack,
> I think we'll just have to agree to disagree.
>

hahaha... and you prove my point.

Cheers,
-g

RE: RTC vs CTR (was: Concerning Sentry...)

["Dennis E. Hamilton" <de...@acm.org>]

+1

Although an individual taking the RTC route is a bit different than there being a local policy that requires it.  This has been addressed subsequently on this thread, but I am struck by Bertrand's simple statement.  It inspired a different way of looking at RTC vs CTR.  

It is a community strength, and even related to having committer karma at all, that folks are considered trustworthy to make changes (C[TR]) in repositories where they are competent and careful, and that they are trusted to know the difference where RTC is called for when they are not so confident and consider determination/review as a way of avoiding unintended consequences.  

There is also the safeguard that review is always possible and, indeed, we are presumably talking about the one place where vetos count.

That does not mean mistakes do not happen, that no one is ever hasty, bull-headed, etc., etc.  We're all human and these projects are human enterprises.  The idea is that mutual trust based on a shared commitment prevails as a guiding force through the hurly-burly of all that.  And out of that, a trustworthy (not some abstractly perfect) outcome is achieved.  By trustworthy, to be clear, I mean that the result shows care for the ultimate recipients of the work and when there are breakdowns, they are resolved in a manner that demonstrates that care.

It seems then, that having some sort of blanket policy one way or the other is about some magical view of a perfection where there is none to be found, only folks stumbling along doing their best.  We want to honor that, and the guiding principle is that community is where it arises.

 - Dennis 

PS: From another context, but one that might be useful here: To be trustworthy, one must first be willing to trust.  (From this, you could surmise why I personally find ALv2 preferable to GPL in the work that I do and why I find ASF's approach to serving the public good so harmonious.)

> -----Original Message-----
> From: Bertrand Delacretaz [mailto:bdelacretaz@apache.org]
> Sent: Monday, November 16, 2015 23:53
> To: Incubator General <ge...@incubator.apache.org>
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> 
> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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".
> 
> Like all sharp tools I think RTC has its place, but shouldn't be
> abused. It's perfectly possible to have some parts of a project's code
> under RTC and others under CTR.
> 
> -Bertrand
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@apache.org>]

On Wed, Nov 25, 2015 at 7:06 PM, Ralph Goers <ra...@dslextreme.com>
wrote:


> Much as I don’t care to participate in GPL projects I also don’t care to
> participate in pure RTC projects as both restrict me in ways I very much
> dislike,
>
>
You're entitled to that opinion. I personally don't care to participate in
CTR projects. So, as stated above, let's agree to disagree, and let each
community within Apache decide for themselves.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers <ra...@dslextreme.com>]

> On Nov 25, 2015, at 3:22 PM, Todd Lipcon <to...@apache.org> wrote:
> 
> Isn't it an issue of scalability? With pre-commit code reviews, typically
> the uploader of the code will pick out one or two people to review the code
> who know the area well. Or, if no one is picked by the submitter of the
> patch, the committers will organically end up deciding who is to review the
> code, at which point that reviewer ends up being a sort of shepherd for the
> patch, sticking with the contributor through multiple revs until it's ready
> for commit.
> 
> With post-commit review, do you expect to watch the mailing list and review
> every patch that comes in? In a project like Hadoop, that's not feasible --
> we've had ~35,000 lines of code changed in the last month in 267 patches.
> If everyone tries to review every patch post-commit, you end up with n^2
> work as the community grows.

Maven is a large project with a decent number of committers. People naturally pick their areas and review the code in their areas of interest because it is important to them. Maven also has a large suite of integration tests for the core and a group of people who are interested in that. Each of the Maven plugins has a group of people who gravitate towards them. No one really has to assign anything.

With Log4j we have one individual who commits a lot but most of his commits are to change variable names, fix javadoc bugs, and other general code cleanup tasks.  I will look at the commit log message and won’t review those directly because I know that is what he is doing. But when he makes a code change with a Jira issue tag I will do my best to review that. That won’t be reflected on the dev list because I only comment when I find something that needs to be updated.

The major difference I see between the CTR projects and the RTC projects is that the RTC projects mandate that everything has to go through the review-then-commit process.  CTR projects a) allow portions of the project to be RTC or b) allow committers to choose to use RTC for specific commits.  It is almost like we are dealing with the difference between the GPL, where the code is supposedly free, and non-copyleft licenses where the user is free. Both can get the job done but both come with a different set of benefits and costs. Much as I don’t care to participate in GPL projects I also don’t care to participate in pure RTC projects as both restrict me in ways I very much dislike,

Ralph




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@apache.org>]

On Wed, Nov 25, 2015 at 1:32 PM, Ralph Goers <ra...@dslextreme.com>
wrote:

> 1. What makes you think all bugs are caught during code reviews (they
> aren’t)?
>

They aren't. But some are. And catching them in code review is cheaper than
catching them when a user hits them.

Additionally, plenty of other things are caught in code reviews other than
bugs (style, compat issues, design issues, poor test coverage, etc)


> 2. What makes you think that code reviews after the commit are any less
> thorough than reviews required before the commit?
>
> If you don’t trust your community to do code reviews after you commit then
> there is a problem in your community. Forcing a code review to occur first
> won’t fix that.
>

Isn't it an issue of scalability? With pre-commit code reviews, typically
the uploader of the code will pick out one or two people to review the code
who know the area well. Or, if no one is picked by the submitter of the
patch, the committers will organically end up deciding who is to review the
code, at which point that reviewer ends up being a sort of shepherd for the
patch, sticking with the contributor through multiple revs until it's ready
for commit.

With post-commit review, do you expect to watch the mailing list and review
every patch that comes in? In a project like Hadoop, that's not feasible --
we've had ~35,000 lines of code changed in the last month in 267 patches.
If everyone tries to review every patch post-commit, you end up with n^2
work as the community grows.

Amusingly enough, I happened upon a chapter in "Producing Open Source
Software" that invoke's Greg's name on the subject of open source code
review (http://producingoss.com/en/setting-tone.html):

 There was no guarantee that every commit would be reviewed, though one
> might sometimes look over a change if one were particularly interested in
> that area of the code. Bugs slipped in that really could and should have
> been caught. A developer named Greg Stein, who knew the value of code
> review from past work, decided that he was going to set an example by
> reviewing every line of every single commit that went into the code
> repository. Each commit anyone made was soon followed by an email to the
> developer's list from Greg, dissecting the commit, analyzing possible
> problems, and occasionally praising a clever bit of code.


I'm impressed that Greg was able to do this with Subversion, but not sure
how it could work in a faster paced project, and also feel like this
practice produces a serious "bus factor" issue.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

On Nov 25, 2015, at 11:32 PM, Ralph Goers <ra...@dslextreme.com> wrote:

> 1. What makes you think all bugs are caught during code reviews (they aren’t)?

I don’t, and I did not infer that.

> 2. What makes you think that code reviews after the commit are any less thorough than reviews required before the commit?

Nothing. I did not say that. If the code review is done, it makes no difference when. I only said that CTR insures that the CODE REVIEW IS ACTUALLY DONE.

> If you don’t trust your community to do code reviews after you commit then there is a problem in your community. Forcing a code review to occur first won’t fix that.
> 
I don’t see it as not trusting the community. I think Flex is doing just fine right now. But Flex is a big code base and there’s areas where not a lot of people work on it. Especially, on a big code-base, there’s people working on different things. It’s totally reasonable for something to go under everyone’s radar — especially in an area of the code where there are not a lot of people working on it. Mandatory code reviews seems to me a method of making sure that it doesn’t get missed. If the code doesn’t get reviewed after x number of days, the person who's committing can send an email to the list asking for someone to look it over. What’s wrong with that?

> In a CTR world you can choose to do every piece of work on a branch and ask for a code review before you commit. That is your choice.  But if you know that the code you are committing is good because you have a thorough knowledge of your product you shouldn’t be forced to have it reviewed before you can commit it.  I actually love the line in Kudu where it says that automation insures quality. I am a big fan of that. In my experience having lots of tests is the best way to insure stuff doesn’t get broken.
> 
> So how did you catch the bugs in your code in Flex?  Would you have preferred that they stay on a branch for months so they could be reviewed before committing?  Despite how great people say git is I have still had lots of problems resolving merge conflicts when the code isn’t merged back quickly.  If I understand what you are saying you would prefer that Flex use RTC because you don’t trust your fellow committers to review your code.  That is a community problem that needs to be fixed. Forcing them to review the code first isn’t the proper way to fix it.

The bugs were found after the last release of Flex and reported by users.

No. I’m not saying I want RTC. I don’t. I’m quite happy with CTR in my community. Small bugs in Flex even if not caught will not likely cause users millions of dollars. I’m okay if there might be more bugs in Flex and not requiring code review, because code review DOES make things more difficult. All I’m saying is that I understand the rationale as quality assurance for communities who consider the damage for regressive bugs to be very high. It seems like a certain amount of RTC can be a reasonable price to pay.


> Ralph
> 
>> On Nov 25, 2015, at 2:00 PM, Harbs <ha...@gmail.com> wrote:
>> 
>> If a review is required for non-code changes to the main branch, then I agree.
>> 
>> I’m sure you agree that reviews on code make for less bugs. We all make mistakes and can overlook things. It seems kind of extreme to assume that this kind of required review is all about control. Since anyone who can commit can review, it’s kind of hard for me to swallow that.
>> 
>> I assume your logic is that the reviews can come after the commit. Sure. But what if it doesn’t?
>> 
>> Case in point: I made some pretty major changes to TLF in Flex which constituted a number of months of work. I’m willing to bet that not every commit I did was checked by others. I did a decent job, but there were a few regressive bugs in my code, and I accidentally reverted some code in my commit as well. In a workflow where my code would have to get one or more +1s before I committed it to the main branch, it’s likely that the reverted commit (at the least) would have been caught.
>> 
>> I would actually welcome knowing someone looked over my code for a sanity check.
>> 
>> Harbs
>> 
>> On Nov 25, 2015, at 10:49 PM, Greg Stein <gs...@gmail.com> wrote:
>> 
>>> That is pretty normal operation in both styles of workflow. My concern is
>>> with trunk/master. Is a committer trusted enough to make changes directly?
>>> 
>>> If all meaningful changes (ie. changing APIs and algorithms, not just
>>> fixing typos w/o review) are not trusted, and require review/permission,
>>> then I'm against that.
>>> 
>>> It is good practice to put potentially disruptive code onto a branch while
>>> it is developed, then merge it when complete. Trusting a committer to ask
>>> for review before the merge is great. Requiring it, less so.
>>> 
>>> But RTC on trunk/master is harmful.
>>> 
>>> Cheers,
>>> -g
>>> 
>>> On Wed, Nov 25, 2015 at 2:44 PM, Harbs <ha...@gmail.com> wrote:
>>> 
>>>> What about commit to feature/bug brach, review and then commit to main
>>>> branch?
>>>> 
>>>> Is that CTR or RTC in your book?
>>>> 
>>>> On Nov 25, 2015, at 10:42 PM, Greg Stein <gs...@gmail.com> wrote:
>>>> 
>>>>> I object to Lucene's path, too. A committer's judgement is not trusted
>>>>> enough to make a change without upload/review. They need permission first
>>>>> (again: to use your term; it works great).
>>>>> 
>>>>> On Wed, Nov 25, 2015 at 2:39 PM, Upayavira <uv...@odoko.co.uk> wrote:
>>>>> 
>>>>>> Some setups that people call RTC are actually CTR in your nomenclature,
>>>>>> so we could be talking cross-purposes. That's all I'm trying to avoid.
>>>>>> E.g. Lucene - everything happens in JIRA first (upload patch, wait for
>>>>>> review), but once that has happened, you are free to commit away. So
>>>>>> strictly, it is RTC, but not seemingly in the sense you are objecting
>>>>>> to.
>>>>>> 
>>>>>> Upayavira
>>>>>> 
>>>>>> On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
>>>>>>> I think this is a distraction. You said it best the other day: RTC
>>>>>>> implies
>>>>>>> the need for "permission" before making a change to the codebase.
>>>>>>> Committers are not trusted to make a judgement on whether a change
>>>> should
>>>>>>> be made.
>>>>>>> 
>>>>>>> CTR trusts committers to use their judgement. RTC distrusts committers,
>>>>>>> and
>>>>>>> makes them seek permission [though one of several mechanisms].
>>>>>>> 
>>>>>>> -g
>>>>>>> 
>>>>>>> On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:
>>>>>>> 
>>>>>>>> Not replying to this mail specifically, but to the thread in
>>>> general...
>>>>>>>> 
>>>>>>>> People keep using the terms RTC and CTR as if we all mean the same
>>>>>>>> thing. Please don't. If you must use these terms, please define what
>>>>>> you
>>>>>>>> mean by them.
>>>>>>>> 
>>>>>>>> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
>>>>>>>> means a push to a version control system.
>>>>>>>> 
>>>>>>>> However, RTC seems to mean many things - from "push to JIRA for review
>>>>>>>> first, wait a bit, then commit to VCS" through "push to JIRA, and once
>>>>>>>> you have sufficient +1 votes, you can commit" to "push to JIRA for a
>>>>>>>> review, then another committer must commit it".
>>>>>>>> 
>>>>>>>> If we're gonna debate RTC, can we please describe which of these we
>>>> are
>>>>>>>> talking about (or some other mechanism that I haven't described)?
>>>>>>>> Otherwise, we will end up endlessly debating over the top of each
>>>>>> other.
>>>>>>>> 
>>>>>>>> Upayavira
>>>>>>>> 
>>>>>>>> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
>>>>>>>>> AIUI, there’s two ways to go about RTC which is easier in Git:
>>>>>>>>> 1) Working in feature/bug fix branches. Assuming RTC only applies to
>>>>>> the
>>>>>>>>> main branch, changes are done in separate branches where commits do
>>>>>> not
>>>>>>>>> require review. The feature/bug fix branch is then only merged back
>>>>>> in
>>>>>>>>> after it had a review. The reason this is easier is because
>>>>>> branching and
>>>>>>>>> merging is almost zero effort in Git. Many Git workflows don’t work
>>>>>> on
>>>>>>>>> the main branch anyway, so this is a particularly good fit for those
>>>>>>>>> workflows.
>>>>>>>>> 2) Pull requests. Using pull requests, all changes can be pulled in
>>>>>> with
>>>>>>>>> a single command.
>>>>>>>>> 
>>>>>>>>> I’ve personally never participated in RTC (unless you count Github
>>>>>>>>> projects and before I was a committer in Flex), so it could be I’m
>>>>>>>>> missing something.
>>>>>>>>> 
>>>>>>>>> Of course there’s nothing to ENFORCE that the commit is not done
>>>>>> before a
>>>>>>>>> review, but why would you want to do that? That’s where trust comes
>>>>>> to
>>>>>>>>> play… ;-)
>>>>>>>>> 
>>>>>>>>> Harbs
>>>>>>>>> 
>>>>>>>>> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> I don't think Git is particularly empowering RTC - there's nothing
>>>>>> in
>>>>>>>> it that
>>>>>>>>>> requires someone to look over one's shoulder.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>> 
>>>> 
>> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers <ra...@dslextreme.com>]

1. What makes you think all bugs are caught during code reviews (they aren’t)?
2. What makes you think that code reviews after the commit are any less thorough than reviews required before the commit?

If you don’t trust your community to do code reviews after you commit then there is a problem in your community. Forcing a code review to occur first won’t fix that.

In a CTR world you can choose to do every piece of work on a branch and ask for a code review before you commit. That is your choice.  But if you know that the code you are committing is good because you have a thorough knowledge of your product you shouldn’t be forced to have it reviewed before you can commit it.  I actually love the line in Kudu where it says that automation insures quality. I am a big fan of that. In my experience having lots of tests is the best way to insure stuff doesn’t get broken.

So how did you catch the bugs in your code in Flex?  Would you have preferred that they stay on a branch for months so they could be reviewed before committing?  Despite how great people say git is I have still had lots of problems resolving merge conflicts when the code isn’t merged back quickly.  If I understand what you are saying you would prefer that Flex use RTC because you don’t trust your fellow committers to review your code.  That is a community problem that needs to be fixed. Forcing them to review the code first isn’t the proper way to fix it.

Ralph

> On Nov 25, 2015, at 2:00 PM, Harbs <ha...@gmail.com> wrote:
> 
> If a review is required for non-code changes to the main branch, then I agree.
> 
> I’m sure you agree that reviews on code make for less bugs. We all make mistakes and can overlook things. It seems kind of extreme to assume that this kind of required review is all about control. Since anyone who can commit can review, it’s kind of hard for me to swallow that.
> 
> I assume your logic is that the reviews can come after the commit. Sure. But what if it doesn’t?
> 
> Case in point: I made some pretty major changes to TLF in Flex which constituted a number of months of work. I’m willing to bet that not every commit I did was checked by others. I did a decent job, but there were a few regressive bugs in my code, and I accidentally reverted some code in my commit as well. In a workflow where my code would have to get one or more +1s before I committed it to the main branch, it’s likely that the reverted commit (at the least) would have been caught.
> 
> I would actually welcome knowing someone looked over my code for a sanity check.
> 
> Harbs
> 
> On Nov 25, 2015, at 10:49 PM, Greg Stein <gs...@gmail.com> wrote:
> 
>> That is pretty normal operation in both styles of workflow. My concern is
>> with trunk/master. Is a committer trusted enough to make changes directly?
>> 
>> If all meaningful changes (ie. changing APIs and algorithms, not just
>> fixing typos w/o review) are not trusted, and require review/permission,
>> then I'm against that.
>> 
>> It is good practice to put potentially disruptive code onto a branch while
>> it is developed, then merge it when complete. Trusting a committer to ask
>> for review before the merge is great. Requiring it, less so.
>> 
>> But RTC on trunk/master is harmful.
>> 
>> Cheers,
>> -g
>> 
>> On Wed, Nov 25, 2015 at 2:44 PM, Harbs <ha...@gmail.com> wrote:
>> 
>>> What about commit to feature/bug brach, review and then commit to main
>>> branch?
>>> 
>>> Is that CTR or RTC in your book?
>>> 
>>> On Nov 25, 2015, at 10:42 PM, Greg Stein <gs...@gmail.com> wrote:
>>> 
>>>> I object to Lucene's path, too. A committer's judgement is not trusted
>>>> enough to make a change without upload/review. They need permission first
>>>> (again: to use your term; it works great).
>>>> 
>>>> On Wed, Nov 25, 2015 at 2:39 PM, Upayavira <uv...@odoko.co.uk> wrote:
>>>> 
>>>>> Some setups that people call RTC are actually CTR in your nomenclature,
>>>>> so we could be talking cross-purposes. That's all I'm trying to avoid.
>>>>> E.g. Lucene - everything happens in JIRA first (upload patch, wait for
>>>>> review), but once that has happened, you are free to commit away. So
>>>>> strictly, it is RTC, but not seemingly in the sense you are objecting
>>>>> to.
>>>>> 
>>>>> Upayavira
>>>>> 
>>>>> On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
>>>>>> I think this is a distraction. You said it best the other day: RTC
>>>>>> implies
>>>>>> the need for "permission" before making a change to the codebase.
>>>>>> Committers are not trusted to make a judgement on whether a change
>>> should
>>>>>> be made.
>>>>>> 
>>>>>> CTR trusts committers to use their judgement. RTC distrusts committers,
>>>>>> and
>>>>>> makes them seek permission [though one of several mechanisms].
>>>>>> 
>>>>>> -g
>>>>>> 
>>>>>> On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:
>>>>>> 
>>>>>>> Not replying to this mail specifically, but to the thread in
>>> general...
>>>>>>> 
>>>>>>> People keep using the terms RTC and CTR as if we all mean the same
>>>>>>> thing. Please don't. If you must use these terms, please define what
>>>>> you
>>>>>>> mean by them.
>>>>>>> 
>>>>>>> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
>>>>>>> means a push to a version control system.
>>>>>>> 
>>>>>>> However, RTC seems to mean many things - from "push to JIRA for review
>>>>>>> first, wait a bit, then commit to VCS" through "push to JIRA, and once
>>>>>>> you have sufficient +1 votes, you can commit" to "push to JIRA for a
>>>>>>> review, then another committer must commit it".
>>>>>>> 
>>>>>>> If we're gonna debate RTC, can we please describe which of these we
>>> are
>>>>>>> talking about (or some other mechanism that I haven't described)?
>>>>>>> Otherwise, we will end up endlessly debating over the top of each
>>>>> other.
>>>>>>> 
>>>>>>> Upayavira
>>>>>>> 
>>>>>>> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
>>>>>>>> AIUI, there’s two ways to go about RTC which is easier in Git:
>>>>>>>> 1) Working in feature/bug fix branches. Assuming RTC only applies to
>>>>> the
>>>>>>>> main branch, changes are done in separate branches where commits do
>>>>> not
>>>>>>>> require review. The feature/bug fix branch is then only merged back
>>>>> in
>>>>>>>> after it had a review. The reason this is easier is because
>>>>> branching and
>>>>>>>> merging is almost zero effort in Git. Many Git workflows don’t work
>>>>> on
>>>>>>>> the main branch anyway, so this is a particularly good fit for those
>>>>>>>> workflows.
>>>>>>>> 2) Pull requests. Using pull requests, all changes can be pulled in
>>>>> with
>>>>>>>> a single command.
>>>>>>>> 
>>>>>>>> I’ve personally never participated in RTC (unless you count Github
>>>>>>>> projects and before I was a committer in Flex), so it could be I’m
>>>>>>>> missing something.
>>>>>>>> 
>>>>>>>> Of course there’s nothing to ENFORCE that the commit is not done
>>>>> before a
>>>>>>>> review, but why would you want to do that? That’s where trust comes
>>>>> to
>>>>>>>> play… ;-)
>>>>>>>> 
>>>>>>>> Harbs
>>>>>>>> 
>>>>>>>> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org>
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I don't think Git is particularly empowering RTC - there's nothing
>>>>> in
>>>>>>> it that
>>>>>>>>> requires someone to look over one's shoulder.
>>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>> 
>>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>> 
>>> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

If a review is required for non-code changes to the main branch, then I agree.

I’m sure you agree that reviews on code make for less bugs. We all make mistakes and can overlook things. It seems kind of extreme to assume that this kind of required review is all about control. Since anyone who can commit can review, it’s kind of hard for me to swallow that.

I assume your logic is that the reviews can come after the commit. Sure. But what if it doesn’t?

Case in point: I made some pretty major changes to TLF in Flex which constituted a number of months of work. I’m willing to bet that not every commit I did was checked by others. I did a decent job, but there were a few regressive bugs in my code, and I accidentally reverted some code in my commit as well. In a workflow where my code would have to get one or more +1s before I committed it to the main branch, it’s likely that the reverted commit (at the least) would have been caught.

I would actually welcome knowing someone looked over my code for a sanity check.

Harbs

On Nov 25, 2015, at 10:49 PM, Greg Stein <gs...@gmail.com> wrote:

> That is pretty normal operation in both styles of workflow. My concern is
> with trunk/master. Is a committer trusted enough to make changes directly?
> 
> If all meaningful changes (ie. changing APIs and algorithms, not just
> fixing typos w/o review) are not trusted, and require review/permission,
> then I'm against that.
> 
> It is good practice to put potentially disruptive code onto a branch while
> it is developed, then merge it when complete. Trusting a committer to ask
> for review before the merge is great. Requiring it, less so.
> 
> But RTC on trunk/master is harmful.
> 
> Cheers,
> -g
> 
> On Wed, Nov 25, 2015 at 2:44 PM, Harbs <ha...@gmail.com> wrote:
> 
>> What about commit to feature/bug brach, review and then commit to main
>> branch?
>> 
>> Is that CTR or RTC in your book?
>> 
>> On Nov 25, 2015, at 10:42 PM, Greg Stein <gs...@gmail.com> wrote:
>> 
>>> I object to Lucene's path, too. A committer's judgement is not trusted
>>> enough to make a change without upload/review. They need permission first
>>> (again: to use your term; it works great).
>>> 
>>> On Wed, Nov 25, 2015 at 2:39 PM, Upayavira <uv...@odoko.co.uk> wrote:
>>> 
>>>> Some setups that people call RTC are actually CTR in your nomenclature,
>>>> so we could be talking cross-purposes. That's all I'm trying to avoid.
>>>> E.g. Lucene - everything happens in JIRA first (upload patch, wait for
>>>> review), but once that has happened, you are free to commit away. So
>>>> strictly, it is RTC, but not seemingly in the sense you are objecting
>>>> to.
>>>> 
>>>> Upayavira
>>>> 
>>>> On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
>>>>> I think this is a distraction. You said it best the other day: RTC
>>>>> implies
>>>>> the need for "permission" before making a change to the codebase.
>>>>> Committers are not trusted to make a judgement on whether a change
>> should
>>>>> be made.
>>>>> 
>>>>> CTR trusts committers to use their judgement. RTC distrusts committers,
>>>>> and
>>>>> makes them seek permission [though one of several mechanisms].
>>>>> 
>>>>> -g
>>>>> 
>>>>> On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:
>>>>> 
>>>>>> Not replying to this mail specifically, but to the thread in
>> general...
>>>>>> 
>>>>>> People keep using the terms RTC and CTR as if we all mean the same
>>>>>> thing. Please don't. If you must use these terms, please define what
>>>> you
>>>>>> mean by them.
>>>>>> 
>>>>>> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
>>>>>> means a push to a version control system.
>>>>>> 
>>>>>> However, RTC seems to mean many things - from "push to JIRA for review
>>>>>> first, wait a bit, then commit to VCS" through "push to JIRA, and once
>>>>>> you have sufficient +1 votes, you can commit" to "push to JIRA for a
>>>>>> review, then another committer must commit it".
>>>>>> 
>>>>>> If we're gonna debate RTC, can we please describe which of these we
>> are
>>>>>> talking about (or some other mechanism that I haven't described)?
>>>>>> Otherwise, we will end up endlessly debating over the top of each
>>>> other.
>>>>>> 
>>>>>> Upayavira
>>>>>> 
>>>>>> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
>>>>>>> AIUI, there’s two ways to go about RTC which is easier in Git:
>>>>>>> 1) Working in feature/bug fix branches. Assuming RTC only applies to
>>>> the
>>>>>>> main branch, changes are done in separate branches where commits do
>>>> not
>>>>>>> require review. The feature/bug fix branch is then only merged back
>>>> in
>>>>>>> after it had a review. The reason this is easier is because
>>>> branching and
>>>>>>> merging is almost zero effort in Git. Many Git workflows don’t work
>>>> on
>>>>>>> the main branch anyway, so this is a particularly good fit for those
>>>>>>> workflows.
>>>>>>> 2) Pull requests. Using pull requests, all changes can be pulled in
>>>> with
>>>>>>> a single command.
>>>>>>> 
>>>>>>> I’ve personally never participated in RTC (unless you count Github
>>>>>>> projects and before I was a committer in Flex), so it could be I’m
>>>>>>> missing something.
>>>>>>> 
>>>>>>> Of course there’s nothing to ENFORCE that the commit is not done
>>>> before a
>>>>>>> review, but why would you want to do that? That’s where trust comes
>>>> to
>>>>>>> play… ;-)
>>>>>>> 
>>>>>>> Harbs
>>>>>>> 
>>>>>>> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org>
>>>> wrote:
>>>>>>> 
>>>>>>>> I don't think Git is particularly empowering RTC - there's nothing
>>>> in
>>>>>> it that
>>>>>>>> requires someone to look over one's shoulder.
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>> 
>>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 

Re: RTC vs CTR (was: Concerning Sentry...)

[Jim Jagielski <ji...@jaguNET.com>]

> On Nov 25, 2015, at 3:49 PM, Greg Stein <gs...@gmail.com> wrote:
> 
> That is pretty normal operation in both styles of workflow. My concern is
> with trunk/master.

As far as I know, that condition was unclear... You seemed
to imply that RTC *anyplace* was harmful or all about control.

Both CTR and RTC are processes, with known reasons, rationales,
scenarios and use-cases. It's HOW they are used which is
the rub.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

That is pretty normal operation in both styles of workflow. My concern is
with trunk/master. Is a committer trusted enough to make changes directly?

If all meaningful changes (ie. changing APIs and algorithms, not just
fixing typos w/o review) are not trusted, and require review/permission,
then I'm against that.

It is good practice to put potentially disruptive code onto a branch while
it is developed, then merge it when complete. Trusting a committer to ask
for review before the merge is great. Requiring it, less so.

But RTC on trunk/master is harmful.

Cheers,
-g

On Wed, Nov 25, 2015 at 2:44 PM, Harbs <ha...@gmail.com> wrote:

> What about commit to feature/bug brach, review and then commit to main
> branch?
>
> Is that CTR or RTC in your book?
>
> On Nov 25, 2015, at 10:42 PM, Greg Stein <gs...@gmail.com> wrote:
>
> > I object to Lucene's path, too. A committer's judgement is not trusted
> > enough to make a change without upload/review. They need permission first
> > (again: to use your term; it works great).
> >
> > On Wed, Nov 25, 2015 at 2:39 PM, Upayavira <uv...@odoko.co.uk> wrote:
> >
> >> Some setups that people call RTC are actually CTR in your nomenclature,
> >> so we could be talking cross-purposes. That's all I'm trying to avoid.
> >> E.g. Lucene - everything happens in JIRA first (upload patch, wait for
> >> review), but once that has happened, you are free to commit away. So
> >> strictly, it is RTC, but not seemingly in the sense you are objecting
> >> to.
> >>
> >> Upayavira
> >>
> >> On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
> >>> I think this is a distraction. You said it best the other day: RTC
> >>> implies
> >>> the need for "permission" before making a change to the codebase.
> >>> Committers are not trusted to make a judgement on whether a change
> should
> >>> be made.
> >>>
> >>> CTR trusts committers to use their judgement. RTC distrusts committers,
> >>> and
> >>> makes them seek permission [though one of several mechanisms].
> >>>
> >>> -g
> >>>
> >>> On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:
> >>>
> >>>> Not replying to this mail specifically, but to the thread in
> general...
> >>>>
> >>>> People keep using the terms RTC and CTR as if we all mean the same
> >>>> thing. Please don't. If you must use these terms, please define what
> >> you
> >>>> mean by them.
> >>>>
> >>>> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
> >>>> means a push to a version control system.
> >>>>
> >>>> However, RTC seems to mean many things - from "push to JIRA for review
> >>>> first, wait a bit, then commit to VCS" through "push to JIRA, and once
> >>>> you have sufficient +1 votes, you can commit" to "push to JIRA for a
> >>>> review, then another committer must commit it".
> >>>>
> >>>> If we're gonna debate RTC, can we please describe which of these we
> are
> >>>> talking about (or some other mechanism that I haven't described)?
> >>>> Otherwise, we will end up endlessly debating over the top of each
> >> other.
> >>>>
> >>>> Upayavira
> >>>>
> >>>> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
> >>>>> AIUI, there’s two ways to go about RTC which is easier in Git:
> >>>>> 1) Working in feature/bug fix branches. Assuming RTC only applies to
> >> the
> >>>>> main branch, changes are done in separate branches where commits do
> >> not
> >>>>> require review. The feature/bug fix branch is then only merged back
> >> in
> >>>>> after it had a review. The reason this is easier is because
> >> branching and
> >>>>> merging is almost zero effort in Git. Many Git workflows don’t work
> >> on
> >>>>> the main branch anyway, so this is a particularly good fit for those
> >>>>> workflows.
> >>>>> 2) Pull requests. Using pull requests, all changes can be pulled in
> >> with
> >>>>> a single command.
> >>>>>
> >>>>> I’ve personally never participated in RTC (unless you count Github
> >>>>> projects and before I was a committer in Flex), so it could be I’m
> >>>>> missing something.
> >>>>>
> >>>>> Of course there’s nothing to ENFORCE that the commit is not done
> >> before a
> >>>>> review, but why would you want to do that? That’s where trust comes
> >> to
> >>>>> play… ;-)
> >>>>>
> >>>>> Harbs
> >>>>>
> >>>>> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org>
> >> wrote:
> >>>>>
> >>>>>> I don't think Git is particularly empowering RTC - there's nothing
> >> in
> >>>> it that
> >>>>>> requires someone to look over one's shoulder.
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

What about commit to feature/bug brach, review and then commit to main branch?

Is that CTR or RTC in your book?

On Nov 25, 2015, at 10:42 PM, Greg Stein <gs...@gmail.com> wrote:

> I object to Lucene's path, too. A committer's judgement is not trusted
> enough to make a change without upload/review. They need permission first
> (again: to use your term; it works great).
> 
> On Wed, Nov 25, 2015 at 2:39 PM, Upayavira <uv...@odoko.co.uk> wrote:
> 
>> Some setups that people call RTC are actually CTR in your nomenclature,
>> so we could be talking cross-purposes. That's all I'm trying to avoid.
>> E.g. Lucene - everything happens in JIRA first (upload patch, wait for
>> review), but once that has happened, you are free to commit away. So
>> strictly, it is RTC, but not seemingly in the sense you are objecting
>> to.
>> 
>> Upayavira
>> 
>> On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
>>> I think this is a distraction. You said it best the other day: RTC
>>> implies
>>> the need for "permission" before making a change to the codebase.
>>> Committers are not trusted to make a judgement on whether a change should
>>> be made.
>>> 
>>> CTR trusts committers to use their judgement. RTC distrusts committers,
>>> and
>>> makes them seek permission [though one of several mechanisms].
>>> 
>>> -g
>>> 
>>> On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:
>>> 
>>>> Not replying to this mail specifically, but to the thread in general...
>>>> 
>>>> People keep using the terms RTC and CTR as if we all mean the same
>>>> thing. Please don't. If you must use these terms, please define what
>> you
>>>> mean by them.
>>>> 
>>>> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
>>>> means a push to a version control system.
>>>> 
>>>> However, RTC seems to mean many things - from "push to JIRA for review
>>>> first, wait a bit, then commit to VCS" through "push to JIRA, and once
>>>> you have sufficient +1 votes, you can commit" to "push to JIRA for a
>>>> review, then another committer must commit it".
>>>> 
>>>> If we're gonna debate RTC, can we please describe which of these we are
>>>> talking about (or some other mechanism that I haven't described)?
>>>> Otherwise, we will end up endlessly debating over the top of each
>> other.
>>>> 
>>>> Upayavira
>>>> 
>>>> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
>>>>> AIUI, there’s two ways to go about RTC which is easier in Git:
>>>>> 1) Working in feature/bug fix branches. Assuming RTC only applies to
>> the
>>>>> main branch, changes are done in separate branches where commits do
>> not
>>>>> require review. The feature/bug fix branch is then only merged back
>> in
>>>>> after it had a review. The reason this is easier is because
>> branching and
>>>>> merging is almost zero effort in Git. Many Git workflows don’t work
>> on
>>>>> the main branch anyway, so this is a particularly good fit for those
>>>>> workflows.
>>>>> 2) Pull requests. Using pull requests, all changes can be pulled in
>> with
>>>>> a single command.
>>>>> 
>>>>> I’ve personally never participated in RTC (unless you count Github
>>>>> projects and before I was a committer in Flex), so it could be I’m
>>>>> missing something.
>>>>> 
>>>>> Of course there’s nothing to ENFORCE that the commit is not done
>> before a
>>>>> review, but why would you want to do that? That’s where trust comes
>> to
>>>>> play… ;-)
>>>>> 
>>>>> Harbs
>>>>> 
>>>>> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org>
>> wrote:
>>>>> 
>>>>>> I don't think Git is particularly empowering RTC - there's nothing
>> in
>>>> it that
>>>>>> requires someone to look over one's shoulder.
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

I object to Lucene's path, too. A committer's judgement is not trusted
enough to make a change without upload/review. They need permission first
(again: to use your term; it works great).

On Wed, Nov 25, 2015 at 2:39 PM, Upayavira <uv...@odoko.co.uk> wrote:

> Some setups that people call RTC are actually CTR in your nomenclature,
> so we could be talking cross-purposes. That's all I'm trying to avoid.
> E.g. Lucene - everything happens in JIRA first (upload patch, wait for
> review), but once that has happened, you are free to commit away. So
> strictly, it is RTC, but not seemingly in the sense you are objecting
> to.
>
> Upayavira
>
> On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
> > I think this is a distraction. You said it best the other day: RTC
> > implies
> > the need for "permission" before making a change to the codebase.
> > Committers are not trusted to make a judgement on whether a change should
> > be made.
> >
> > CTR trusts committers to use their judgement. RTC distrusts committers,
> > and
> > makes them seek permission [though one of several mechanisms].
> >
> > -g
> >
> > On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:
> >
> > > Not replying to this mail specifically, but to the thread in general...
> > >
> > > People keep using the terms RTC and CTR as if we all mean the same
> > > thing. Please don't. If you must use these terms, please define what
> you
> > > mean by them.
> > >
> > > CTR is a less ambiguous term - I'd suggest we all assume that "commit"
> > > means a push to a version control system.
> > >
> > > However, RTC seems to mean many things - from "push to JIRA for review
> > > first, wait a bit, then commit to VCS" through "push to JIRA, and once
> > > you have sufficient +1 votes, you can commit" to "push to JIRA for a
> > > review, then another committer must commit it".
> > >
> > > If we're gonna debate RTC, can we please describe which of these we are
> > > talking about (or some other mechanism that I haven't described)?
> > > Otherwise, we will end up endlessly debating over the top of each
> other.
> > >
> > > Upayavira
> > >
> > > On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
> > > > AIUI, there’s two ways to go about RTC which is easier in Git:
> > > > 1) Working in feature/bug fix branches. Assuming RTC only applies to
> the
> > > > main branch, changes are done in separate branches where commits do
> not
> > > > require review. The feature/bug fix branch is then only merged back
> in
> > > > after it had a review. The reason this is easier is because
> branching and
> > > > merging is almost zero effort in Git. Many Git workflows don’t work
> on
> > > > the main branch anyway, so this is a particularly good fit for those
> > > > workflows.
> > > > 2) Pull requests. Using pull requests, all changes can be pulled in
> with
> > > > a single command.
> > > >
> > > > I’ve personally never participated in RTC (unless you count Github
> > > > projects and before I was a committer in Flex), so it could be I’m
> > > > missing something.
> > > >
> > > > Of course there’s nothing to ENFORCE that the commit is not done
> before a
> > > > review, but why would you want to do that? That’s where trust comes
> to
> > > > play… ;-)
> > > >
> > > > Harbs
> > > >
> > > > On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > > >
> > > > > I don't think Git is particularly empowering RTC - there's nothing
> in
> > > it that
> > > > > requires someone to look over one's shoulder.
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Upayavira <uv...@odoko.co.uk>]

Some setups that people call RTC are actually CTR in your nomenclature,
so we could be talking cross-purposes. That's all I'm trying to avoid.
E.g. Lucene - everything happens in JIRA first (upload patch, wait for
review), but once that has happened, you are free to commit away. So
strictly, it is RTC, but not seemingly in the sense you are objecting
to.

Upayavira

On Wed, Nov 25, 2015, at 08:35 PM, Greg Stein wrote:
> I think this is a distraction. You said it best the other day: RTC
> implies
> the need for "permission" before making a change to the codebase.
> Committers are not trusted to make a judgement on whether a change should
> be made.
> 
> CTR trusts committers to use their judgement. RTC distrusts committers,
> and
> makes them seek permission [though one of several mechanisms].
> 
> -g
> 
> On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:
> 
> > Not replying to this mail specifically, but to the thread in general...
> >
> > People keep using the terms RTC and CTR as if we all mean the same
> > thing. Please don't. If you must use these terms, please define what you
> > mean by them.
> >
> > CTR is a less ambiguous term - I'd suggest we all assume that "commit"
> > means a push to a version control system.
> >
> > However, RTC seems to mean many things - from "push to JIRA for review
> > first, wait a bit, then commit to VCS" through "push to JIRA, and once
> > you have sufficient +1 votes, you can commit" to "push to JIRA for a
> > review, then another committer must commit it".
> >
> > If we're gonna debate RTC, can we please describe which of these we are
> > talking about (or some other mechanism that I haven't described)?
> > Otherwise, we will end up endlessly debating over the top of each other.
> >
> > Upayavira
> >
> > On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
> > > AIUI, there’s two ways to go about RTC which is easier in Git:
> > > 1) Working in feature/bug fix branches. Assuming RTC only applies to the
> > > main branch, changes are done in separate branches where commits do not
> > > require review. The feature/bug fix branch is then only merged back in
> > > after it had a review. The reason this is easier is because branching and
> > > merging is almost zero effort in Git. Many Git workflows don’t work on
> > > the main branch anyway, so this is a particularly good fit for those
> > > workflows.
> > > 2) Pull requests. Using pull requests, all changes can be pulled in with
> > > a single command.
> > >
> > > I’ve personally never participated in RTC (unless you count Github
> > > projects and before I was a committer in Flex), so it could be I’m
> > > missing something.
> > >
> > > Of course there’s nothing to ENFORCE that the commit is not done before a
> > > review, but why would you want to do that? That’s where trust comes to
> > > play… ;-)
> > >
> > > Harbs
> > >
> > > On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org> wrote:
> > >
> > > > I don't think Git is particularly empowering RTC - there's nothing in
> > it that
> > > > requires someone to look over one's shoulder.
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

I think this is a distraction. You said it best the other day: RTC implies
the need for "permission" before making a change to the codebase.
Committers are not trusted to make a judgement on whether a change should
be made.

CTR trusts committers to use their judgement. RTC distrusts committers, and
makes them seek permission [though one of several mechanisms].

-g

On Wed, Nov 25, 2015 at 10:47 AM, Upayavira <uv...@odoko.co.uk> wrote:

> Not replying to this mail specifically, but to the thread in general...
>
> People keep using the terms RTC and CTR as if we all mean the same
> thing. Please don't. If you must use these terms, please define what you
> mean by them.
>
> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
> means a push to a version control system.
>
> However, RTC seems to mean many things - from "push to JIRA for review
> first, wait a bit, then commit to VCS" through "push to JIRA, and once
> you have sufficient +1 votes, you can commit" to "push to JIRA for a
> review, then another committer must commit it".
>
> If we're gonna debate RTC, can we please describe which of these we are
> talking about (or some other mechanism that I haven't described)?
> Otherwise, we will end up endlessly debating over the top of each other.
>
> Upayavira
>
> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
> > AIUI, there’s two ways to go about RTC which is easier in Git:
> > 1) Working in feature/bug fix branches. Assuming RTC only applies to the
> > main branch, changes are done in separate branches where commits do not
> > require review. The feature/bug fix branch is then only merged back in
> > after it had a review. The reason this is easier is because branching and
> > merging is almost zero effort in Git. Many Git workflows don’t work on
> > the main branch anyway, so this is a particularly good fit for those
> > workflows.
> > 2) Pull requests. Using pull requests, all changes can be pulled in with
> > a single command.
> >
> > I’ve personally never participated in RTC (unless you count Github
> > projects and before I was a committer in Flex), so it could be I’m
> > missing something.
> >
> > Of course there’s nothing to ENFORCE that the commit is not done before a
> > review, but why would you want to do that? That’s where trust comes to
> > play… ;-)
> >
> > Harbs
> >
> > On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > > I don't think Git is particularly empowering RTC - there's nothing in
> it that
> > > requires someone to look over one's shoulder.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Stephen Connolly <st...@gmail.com>]

Spoilsport ;-)

On 25 November 2015 at 16:47, Upayavira <uv...@odoko.co.uk> wrote:

> Not replying to this mail specifically, but to the thread in general...
>
> People keep using the terms RTC and CTR as if we all mean the same
> thing. Please don't. If you must use these terms, please define what you
> mean by them.
>
> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
> means a push to a version control system.
>
> However, RTC seems to mean many things - from "push to JIRA for review
> first, wait a bit, then commit to VCS" through "push to JIRA, and once
> you have sufficient +1 votes, you can commit" to "push to JIRA for a
> review, then another committer must commit it".
>
> If we're gonna debate RTC, can we please describe which of these we are
> talking about (or some other mechanism that I haven't described)?
> Otherwise, we will end up endlessly debating over the top of each other.
>
> Upayavira
>
> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
> > AIUI, there’s two ways to go about RTC which is easier in Git:
> > 1) Working in feature/bug fix branches. Assuming RTC only applies to the
> > main branch, changes are done in separate branches where commits do not
> > require review. The feature/bug fix branch is then only merged back in
> > after it had a review. The reason this is easier is because branching and
> > merging is almost zero effort in Git. Many Git workflows don’t work on
> > the main branch anyway, so this is a particularly good fit for those
> > workflows.
> > 2) Pull requests. Using pull requests, all changes can be pulled in with
> > a single command.
> >
> > I’ve personally never participated in RTC (unless you count Github
> > projects and before I was a committer in Flex), so it could be I’m
> > missing something.
> >
> > Of course there’s nothing to ENFORCE that the commit is not done before a
> > review, but why would you want to do that? That’s where trust comes to
> > play… ;-)
> >
> > Harbs
> >
> > On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > > I don't think Git is particularly empowering RTC - there's nothing in
> it that
> > > requires someone to look over one's shoulder.
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

Very good point, but I’m not sure that CTR is that much less ambiguous.

It would be interesting to compare different models both that users consider CTR as well as RTC. I have a feeling there is some overlap of “CTR” and “RTC”.

I’m pretty sure that a lot of folks call some CTR cases “RTC”. It’s pretty hard to review changes which are not in a source control system some way or another. Attaching a patch to a JIRA is a pretty clunky way of going about that.

In particular, I’m interested in knowing how much “R” prior to “C” people have trouble with (Greg specifically as he seems to be the most vocal in his opposition). What workflows do “CTR” proponents like to use?

Thanks,
Harbs

On Nov 25, 2015, at 6:47 PM, Upayavira <uv...@odoko.co.uk> wrote:

> Not replying to this mail specifically, but to the thread in general...
> 
> People keep using the terms RTC and CTR as if we all mean the same
> thing. Please don't. If you must use these terms, please define what you
> mean by them.
> 
> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
> means a push to a version control system.
> 
> However, RTC seems to mean many things - from "push to JIRA for review
> first, wait a bit, then commit to VCS" through "push to JIRA, and once
> you have sufficient +1 votes, you can commit" to "push to JIRA for a
> review, then another committer must commit it".
> 
> If we're gonna debate RTC, can we please describe which of these we are
> talking about (or some other mechanism that I haven't described)?
> Otherwise, we will end up endlessly debating over the top of each other.
> 
> Upayavira
> 
> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
>> AIUI, there’s two ways to go about RTC which is easier in Git:
>> 1) Working in feature/bug fix branches. Assuming RTC only applies to the
>> main branch, changes are done in separate branches where commits do not
>> require review. The feature/bug fix branch is then only merged back in
>> after it had a review. The reason this is easier is because branching and
>> merging is almost zero effort in Git. Many Git workflows don’t work on
>> the main branch anyway, so this is a particularly good fit for those
>> workflows.
>> 2) Pull requests. Using pull requests, all changes can be pulled in with
>> a single command.
>> 
>> I’ve personally never participated in RTC (unless you count Github
>> projects and before I was a committer in Flex), so it could be I’m
>> missing something.
>> 
>> Of course there’s nothing to ENFORCE that the commit is not done before a
>> review, but why would you want to do that? That’s where trust comes to
>> play… ;-)
>> 
>> Harbs
>> 
>> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org> wrote:
>> 
>>> I don't think Git is particularly empowering RTC - there's nothing in it that
>>> requires someone to look over one's shoulder.
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Upayavira <uv...@odoko.co.uk>]

Not replying to this mail specifically, but to the thread in general...

People keep using the terms RTC and CTR as if we all mean the same
thing. Please don't. If you must use these terms, please define what you
mean by them.

CTR is a less ambiguous term - I'd suggest we all assume that "commit"
means a push to a version control system.

However, RTC seems to mean many things - from "push to JIRA for review
first, wait a bit, then commit to VCS" through "push to JIRA, and once
you have sufficient +1 votes, you can commit" to "push to JIRA for a
review, then another committer must commit it".

If we're gonna debate RTC, can we please describe which of these we are
talking about (or some other mechanism that I haven't described)?
Otherwise, we will end up endlessly debating over the top of each other.

Upayavira

On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
> AIUI, there’s two ways to go about RTC which is easier in Git:
> 1) Working in feature/bug fix branches. Assuming RTC only applies to the
> main branch, changes are done in separate branches where commits do not
> require review. The feature/bug fix branch is then only merged back in
> after it had a review. The reason this is easier is because branching and
> merging is almost zero effort in Git. Many Git workflows don’t work on
> the main branch anyway, so this is a particularly good fit for those
> workflows.
> 2) Pull requests. Using pull requests, all changes can be pulled in with
> a single command.
> 
> I’ve personally never participated in RTC (unless you count Github
> projects and before I was a committer in Flex), so it could be I’m
> missing something.
> 
> Of course there’s nothing to ENFORCE that the commit is not done before a
> review, but why would you want to do that? That’s where trust comes to
> play… ;-)
> 
> Harbs
> 
> On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > I don't think Git is particularly empowering RTC - there's nothing in it that
> > requires someone to look over one's shoulder.
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

On Nov 25, 2015, at 10:37 PM, Greg Stein <gs...@gmail.com> wrote:

>> AIUI, there’s two ways to go about RTC which is easier in Git:
>> 
> 
> That's not what Cos said. He said using Git does not lead to RTC.
> 
> If RTC has been chosen, then you're right: Git makes it easier [than svn].
> But you've swapped cause/effect from what Cos was saying.

Cos was responding to my email. So if I’m swapping his intent then I’m swapping a swapped intent… ;-)

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org> wrote:
> I don't think Git is particularly empowering RTC - there's nothing in it
that
> requires someone to look over one's shoulder.

On Wed, Nov 25, 2015 at 3:28 AM, Harbs <ha...@gmail.com> wrote:

> AIUI, there’s two ways to go about RTC which is easier in Git:
>

That's not what Cos said. He said using Git does not lead to RTC.

If RTC has been chosen, then you're right: Git makes it easier [than svn].
But you've swapped cause/effect from what Cos was saying.

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

AIUI, there’s two ways to go about RTC which is easier in Git:
1) Working in feature/bug fix branches. Assuming RTC only applies to the main branch, changes are done in separate branches where commits do not require review. The feature/bug fix branch is then only merged back in after it had a review. The reason this is easier is because branching and merging is almost zero effort in Git. Many Git workflows don’t work on the main branch anyway, so this is a particularly good fit for those workflows.
2) Pull requests. Using pull requests, all changes can be pulled in with a single command.

I’ve personally never participated in RTC (unless you count Github projects and before I was a committer in Flex), so it could be I’m missing something.

Of course there’s nothing to ENFORCE that the commit is not done before a review, but why would you want to do that? That’s where trust comes to play… ;-)

Harbs

On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik <co...@apache.org> wrote:

> I don't think Git is particularly empowering RTC - there's nothing in it that
> requires someone to look over one's shoulder.

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Mon, Nov 23, 2015 at 12:29PM, Harbs wrote:
> This kind of underscores my observation that a large part of this debate is
> driven by source control technologies.
> 
> RTC seems popular for projects using Git, while CTR seems popular in
> communities using SVN.

Well, Apache Bigtop is now _officially_ a CTR after a few months of
discussions within the community and a few months of trials. And yeah - we are
using git from day one. 

I don't think Git is particularly empowering RTC - there's nothing in it that
requires someone to look over one's shoulder. In Hadoop, HBase and some other
projects I've heard about the default review mode is via patch attached to a
JIRA ticket. And it has nothing to do with git or svn.

Cos

> RTC is a LOT easier using Git than SVN if the model is branching.
> 
> FWIW, I personally could swallow using RTC with Git, but I would seriously
> have problems with RTC with SVN.
> 
> On Nov 23, 2015, at 12:20 PM, Greg Stein <gs...@gmail.com> wrote:
> 
> >> 3. community building
> >> 
> >> Lots of successful open source projects, both inside and outside ASF,
> >> employ RTC. As Todd mentioned, almost all the top 10 most starred (on
> >> github) projects use some form of RTC, so it is hard for me to believe that
> >> RTC would hinder community building. Of course, one can always argue that
> >> if those projects had employed CTR, maybe they would've been even more
> >> popular. But then we got into the area that we just have to agree to
> >> disagree.
> >> 
> > 
> > Well, you could also look at openhub.net:
> > https://www.openhub.net/orgs/apache ... I believe those top 10 are *all*
> > CTR. ... in fact, of ALL projects tracked by openhub, httpd and svn are #2
> > and #4 respectively[*]. They are models of communities where trust rules
> > and CTR is the basis of operation.
> > 
> > Using GitHub as a proxy for evaluation skews towards git-based projects,
> > whereas openhub is tool independent.
> 

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Tue, Nov 24, 2015 at 02:00AM, Ross Gardler wrote:
> The suggestion is to add it to the proposal template - that's before incubation starts.

I think this is a great idea!

> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@gmail.com] 
> Sent: Monday, November 23, 2015 5:49 PM
> To: general-incubator <ge...@incubator.apache.org>
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> 
> On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein <gs...@gmail.com> wrote:
> 
> > On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby <ru...@intertwingly.net> wrote:
> >
> > > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
> > > >
> > > > Nobody is forcing anything.
> > > >
> > > > Personally, I am saying RTC is destructive, and am willing to give
> > every
> > > > podling that message.
> > >
> > > If it is truly destructive, SHOULDN'T you/we be trying to force 
> > > something?  And if not, doesn't that mean that it isn't really all 
> > > that destructive?
> > >
> >
> > I believe that I represent a minority position, so no... I'm not going 
> > to suggest changes. I wish to forestall more projects falling into the 
> > RTC trap, but (at the moment) don't believe that it makes sense to 
> > attempt to apply mandates against RTC upon existing communities.
> >
> >
> > >  As a Director, would you consider stop approving reports from ASF 
> > > projects that operate under a RTC model?  If not, aren't you sending 
> > > a mixed message?
> > >
> >
> > I have thought about this, yes. Maybe add a question to the proposal 
> > template, on what form they're thinking about (and where I could 
> > debate the proposal against RTC). And maybe debate podlings who want 
> > to graduate under RTC.
> >
> 
> I think this is too late - if you want to debate it, then it needs to be when projects enter incubation. By the time they're ready to graduate then
> (presumably) things are already going well and theres less impetus to change.
> 
> Niall
> 
> 
> 
> 
> > But as a Director, if the community is producing releases, then I find 
> > it difficult to point to RTC as a problem for that community. It is an 
> > unprovable position: there is no way to state their community could be 
> > better off under CTR.
> >
> >
> > >
> > > - Sam Ruby
> > >
> > > P.S.  To be clear: I am not a fan of RTC when applied to 
> > > release.next branches.
> >
> >
> > I'd appreciate your explanation of this, as "most" CTR communities 
> > apply RTC to a branch as they prepare a release. What disturbs you 
> > about this approach?
> >
> > Cheers,
> > -g
> >

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 23, 2015 at 4:29 AM, Harbs <ha...@gmail.com> wrote:
>...

> FWIW, I personally could swallow using RTC with Git, but I would seriously
> have problems with RTC with SVN.
>

I read this as "RTC sucks, but at least Git makes it suck less."

:-)

(and yes, Git's features naturally provide better support for RTC than svn)

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

This kind of underscores my observation that a large part of this debate is driven by source control technologies.

RTC seems popular for projects using Git, while CTR seems popular in communities using SVN.

RTC is a LOT easier using Git than SVN if the model is branching.

FWIW, I personally could swallow using RTC with Git, but I would seriously have problems with RTC with SVN.

On Nov 23, 2015, at 12:20 PM, Greg Stein <gs...@gmail.com> wrote:

>> 3. community building
>> 
>> Lots of successful open source projects, both inside and outside ASF,
>> employ RTC. As Todd mentioned, almost all the top 10 most starred (on
>> github) projects use some form of RTC, so it is hard for me to believe that
>> RTC would hinder community building. Of course, one can always argue that
>> if those projects had employed CTR, maybe they would've been even more
>> popular. But then we got into the area that we just have to agree to
>> disagree.
>> 
> 
> Well, you could also look at openhub.net:
> https://www.openhub.net/orgs/apache ... I believe those top 10 are *all*
> CTR. ... in fact, of ALL projects tracked by openhub, httpd and svn are #2
> and #4 respectively[*]. They are models of communities where trust rules
> and CTR is the basis of operation.
> 
> Using GitHub as a proxy for evaluation skews towards git-based projects,
> whereas openhub is tool independent.

RE: RTC vs CTR (was: Concerning Sentry...)

[Ross Gardler <Ro...@microsoft.com>]

The suggestion is to add it to the proposal template - that's before incubation starts.

-----Original Message-----
From: Niall Pemberton [mailto:niall.pemberton@gmail.com] 
Sent: Monday, November 23, 2015 5:49 PM
To: general-incubator <ge...@incubator.apache.org>
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein <gs...@gmail.com> wrote:

> On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
> > >
> > > Nobody is forcing anything.
> > >
> > > Personally, I am saying RTC is destructive, and am willing to give
> every
> > > podling that message.
> >
> > If it is truly destructive, SHOULDN'T you/we be trying to force 
> > something?  And if not, doesn't that mean that it isn't really all 
> > that destructive?
> >
>
> I believe that I represent a minority position, so no... I'm not going 
> to suggest changes. I wish to forestall more projects falling into the 
> RTC trap, but (at the moment) don't believe that it makes sense to 
> attempt to apply mandates against RTC upon existing communities.
>
>
> >  As a Director, would you consider stop approving reports from ASF 
> > projects that operate under a RTC model?  If not, aren't you sending 
> > a mixed message?
> >
>
> I have thought about this, yes. Maybe add a question to the proposal 
> template, on what form they're thinking about (and where I could 
> debate the proposal against RTC). And maybe debate podlings who want 
> to graduate under RTC.
>

I think this is too late - if you want to debate it, then it needs to be when projects enter incubation. By the time they're ready to graduate then
(presumably) things are already going well and theres less impetus to change.

Niall




> But as a Director, if the community is producing releases, then I find 
> it difficult to point to RTC as a problem for that community. It is an 
> unprovable position: there is no way to state their community could be 
> better off under CTR.
>
>
> >
> > - Sam Ruby
> >
> > P.S.  To be clear: I am not a fan of RTC when applied to 
> > release.next branches.
>
>
> I'd appreciate your explanation of this, as "most" CTR communities 
> apply RTC to a branch as they prepare a release. What disturbs you 
> about this approach?
>
> Cheers,
> -g
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Niall Pemberton <ni...@gmail.com>]

On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein <gs...@gmail.com> wrote:

> On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
> > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
> > >
> > > Nobody is forcing anything.
> > >
> > > Personally, I am saying RTC is destructive, and am willing to give
> every
> > > podling that message.
> >
> > If it is truly destructive, SHOULDN'T you/we be trying to force
> > something?  And if not, doesn't that mean that it isn't really all
> > that destructive?
> >
>
> I believe that I represent a minority position, so no... I'm not going to
> suggest changes. I wish to forestall more projects falling into the RTC
> trap, but (at the moment) don't believe that it makes sense to attempt to
> apply mandates against RTC upon existing communities.
>
>
> >  As a Director, would you consider stop approving reports from ASF
> > projects that operate under a RTC model?  If not, aren't you sending a
> > mixed message?
> >
>
> I have thought about this, yes. Maybe add a question to the proposal
> template, on what form they're thinking about (and where I could debate the
> proposal against RTC). And maybe debate podlings who want to graduate under
> RTC.
>

I think this is too late - if you want to debate it, then it needs to be
when projects enter incubation. By the time they're ready to graduate then
(presumably) things are already going well and theres less impetus to
change.

Niall




> But as a Director, if the community is producing releases, then I find it
> difficult to point to RTC as a problem for that community. It is an
> unprovable position: there is no way to state their community could be
> better off under CTR.
>
>
> >
> > - Sam Ruby
> >
> > P.S.  To be clear: I am not a fan of RTC when applied to release.next
> > branches.
>
>
> I'd appreciate your explanation of this, as "most" CTR communities apply
> RTC to a branch as they prepare a release. What disturbs you about this
> approach?
>
> Cheers,
> -g
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Mon, Nov 23, 2015 at 7:10 AM, Greg Stein <gs...@gmail.com> wrote:
> On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
>>
>> P.S.  To be clear: I am not a fan of RTC when applied to release.next
>> branches.
>
> I'd appreciate your explanation of this, as "most" CTR communities apply
> RTC to a branch as they prepare a release. What disturbs you about this
> approach?

Agreed that "most" CTR communities apply RTC to a branch as they
prepare a release.  Normally when they do so, there is a branch (could
be trunk or master, could be something else like "develop" or even the
working name for the next release) which is where things intended for
the *next* release go.

I'm generally OK with "please work over there while we prep a
release", which is what I meant by "release.next" branches.

Going a bit further, I can live with RTC when commits are reviewed promptly.

I avoid projects where reviews are mandatory and are done on a time
permitting basis.

> Cheers,
> -g

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby <ru...@intertwingly.net> wrote:

> On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
> >
> > Nobody is forcing anything.
> >
> > Personally, I am saying RTC is destructive, and am willing to give every
> > podling that message.
>
> If it is truly destructive, SHOULDN'T you/we be trying to force
> something?  And if not, doesn't that mean that it isn't really all
> that destructive?
>

I believe that I represent a minority position, so no... I'm not going to
suggest changes. I wish to forestall more projects falling into the RTC
trap, but (at the moment) don't believe that it makes sense to attempt to
apply mandates against RTC upon existing communities.


>  As a Director, would you consider stop approving reports from ASF
> projects that operate under a RTC model?  If not, aren't you sending a
> mixed message?
>

I have thought about this, yes. Maybe add a question to the proposal
template, on what form they're thinking about (and where I could debate the
proposal against RTC). And maybe debate podlings who want to graduate under
RTC.

But as a Director, if the community is producing releases, then I find it
difficult to point to RTC as a problem for that community. It is an
unprovable position: there is no way to state their community could be
better off under CTR.


>
> - Sam Ruby
>
> P.S.  To be clear: I am not a fan of RTC when applied to release.next
> branches.


I'd appreciate your explanation of this, as "most" CTR communities apply
RTC to a branch as they prepare a release. What disturbs you about this
approach?

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Brock Noland <br...@apache.org>]

Great! :)

(I admittedly clipped a clipped message so I apologize for missing
"Nobody is forcing anything.")

On Tue, Nov 24, 2015 at 10:36 PM, Greg Stein <gs...@gmail.com> wrote:
> Thanks, Ross. Quite true. ... and I said as much, but you[Brock] clipped
> it. Right before that "Personally, ...", I wrote this line:
>
> "Nobody is forcing anything."
>
>
> On Wed, Nov 25, 2015 at 12:17 AM, Ross Gardler <Ro...@microsoft.com>
> wrote:
>
>> Brock, I can assure you that's not Greg's style so I doubt you have
>> anything to worry about.
>>
>> -----Original Message-----
>> From: Brock Noland [mailto:brock@apache.org]
>> Sent: Tuesday, November 24, 2015 9:54 PM
>> To: general@incubator.apache.org
>> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>>
>> > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
>> >
>> > Personally, I am saying RTC is destructive, and am willing to give
>> > every podling that message.
>>
>> Delivering that message by informing podlings of your experience is
>> completely acceptable.  However, if anyone attempts to force a podling from
>> RTC, which is common in ASF, to CTR, I'd honestly be exceedingly
>> disgusted.  I am not here to dissuade projects who operate within ASF norms
>> from entering the incubator.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

Thanks, Ross. Quite true. ... and I said as much, but you[Brock] clipped
it. Right before that "Personally, ...", I wrote this line:

"Nobody is forcing anything."


On Wed, Nov 25, 2015 at 12:17 AM, Ross Gardler <Ro...@microsoft.com>
wrote:

> Brock, I can assure you that's not Greg's style so I doubt you have
> anything to worry about.
>
> -----Original Message-----
> From: Brock Noland [mailto:brock@apache.org]
> Sent: Tuesday, November 24, 2015 9:54 PM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
> >
> > Personally, I am saying RTC is destructive, and am willing to give
> > every podling that message.
>
> Delivering that message by informing podlings of your experience is
> completely acceptable.  However, if anyone attempts to force a podling from
> RTC, which is common in ASF, to CTR, I'd honestly be exceedingly
> disgusted.  I am not here to dissuade projects who operate within ASF norms
> from entering the incubator.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

RE: RTC vs CTR (was: Concerning Sentry...)

[Ross Gardler <Ro...@microsoft.com>]

Brock, I can assure you that's not Greg's style so I doubt you have anything to worry about.

-----Original Message-----
From: Brock Noland [mailto:brock@apache.org] 
Sent: Tuesday, November 24, 2015 9:54 PM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

> On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
>
> Personally, I am saying RTC is destructive, and am willing to give 
> every podling that message.

Delivering that message by informing podlings of your experience is completely acceptable.  However, if anyone attempts to force a podling from RTC, which is common in ASF, to CTR, I'd honestly be exceedingly disgusted.  I am not here to dissuade projects who operate within ASF norms from entering the incubator.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Brock Noland <br...@apache.org>]

> On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
>
> Personally, I am saying RTC is destructive, and am willing to give every
> podling that message.

Delivering that message by informing podlings of your experience is
completely acceptable.  However, if anyone attempts to force a podling
from RTC, which is common in ASF, to CTR, I'd honestly be exceedingly
disgusted.  I am not here to dissuade projects who operate within ASF
norms from entering the incubator.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein <gs...@gmail.com> wrote:
>
> Nobody is forcing anything.
>
> Personally, I am saying RTC is destructive, and am willing to give every
> podling that message.

If it is truly destructive, SHOULDN'T you/we be trying to force
something?  And if not, doesn't that mean that it isn't really all
that destructive?

 As a Director, would you consider stop approving reports from ASF
projects that operate under a RTC model?  If not, aren't you sending a
mixed message?

- Sam Ruby

P.S.  To be clear: I am not a fan of RTC when applied to release.next
branches.  I can't conceive of myself wanting to participate in a
community that does so and chooses to use SVN.  And if a community
that used RTC turned out to not be healthy, that would be one of the
first things I would suggest that they explore changing.  But if a
community is healthy (and there demonstrably are quite a number of
healthy communities using RTC), then I personally wouldn't chose to
interfere.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 23, 2015 at 12:33 AM, Reynold Xin <rx...@apache.org> wrote:

> Most non-trivial software projects I worked on (paid or un-paid) have RTC
> culture. I cannot represent every single project, but in the ones that I'm
> closely involved with that use RTC, it is simply part of the culture and
> recognition that mandatory code review improves code quality. (We can
> debate about this in a separate thread, since this is not what this thread
> is about.)
>

Quality has been debated in this thread. "R" stands for Review, and it
occurs in both models. There is no basis for saying that RTC produces
better quality.


> I don't think we should elevate everything to "Apache Way", "trust", or
> "community building". RTC vs CTR is not about:
>
> 1. Apache Way
>
> Given ASF doesn't require RTC vs CTR vs somewhere in between, and different
> TLPs already follow different ways, I don't think any mentor or the
> incubator should force their view upon incubating projects.
>

Nobody is forcing anything.

Personally, I am saying RTC is destructive, and am willing to give every
podling that message.


> 2. Trust
>
> It's just part of a project's process and culture. Greg brought up that RTC
> is an indication of lack of trust and committers are just treated as normal
> contributors: "What I haven't seen is an explanation why a committer must
> be treated the same as a drive-by. Both are subject to requiring
> 'permission' to make even the simplest of changes under RTC."
>
> Committers are required to use JIRA, github, and follow many other
> processes that "drive-by" should follow. I don't see why "code review" is
> different from filing JIRA tickets. In most RTC projects, committers do
> have more rights -- a committer can review somebody else's patch and commit
> it.
>

Please see Branko's note. Committers in an RTC project are disrespected.
They have no more regard than drive-by contributors.


> 3. community building
>
> Lots of successful open source projects, both inside and outside ASF,
> employ RTC. As Todd mentioned, almost all the top 10 most starred (on
> github) projects use some form of RTC, so it is hard for me to believe that
> RTC would hinder community building. Of course, one can always argue that
> if those projects had employed CTR, maybe they would've been even more
> popular. But then we got into the area that we just have to agree to
> disagree.
>

Well, you could also look at openhub.net:
https://www.openhub.net/orgs/apache ... I believe those top 10 are *all*
CTR. ... in fact, of ALL projects tracked by openhub, httpd and svn are #2
and #4 respectively[*]. They are models of communities where trust rules
and CTR is the basis of operation.

Using GitHub as a proxy for evaluation skews towards git-based projects,
whereas openhub is tool independent.

-g

[*] #1 and #3 are Firefox and MySQL, which are both corporate driven; our
CTR/RTC model does not apply; #5 is PHP which seems to use CTR.

RE: RTC vs CTR (was: Concerning Sentry...)

["Dennis E. Hamilton" <de...@acm.org>]

> -----Original Message-----
> From: rxin@databricks.com [mailto:rxin@databricks.com] On Behalf Of
> Reynold Xin
> Sent: Sunday, November 22, 2015 22:33
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> 
[ ... ]
[orcmid] 
> Committers are required to use JIRA, github, and follow many other
> processes that "drive-by" should follow. I don't see why "code review"
> is
> different from filing JIRA tickets. In most RTC projects, committers do
> have more rights -- a committer can review somebody else's patch and
> commit
> it.
[ ... ]
[orcmid] 
Caught my eye.  

In the one place where I see RTC, when it is a committer who proposes RTC, it is that committer who will ultimately make any commit.  

Admittedly, this is in a case where C[TR] is available.  

Even on a project where RTC is the norm, why would not the original committer be allowed to commit, based on whatever adjustments review requires?  (I am not equating this with lazy consensus, although that might be an individual case.)

A formal RTC arrangement as I see described strikes me as similar to situations where (senior) professional engineers are responsible for reviewing and approving the work of others.  I can understand the commitment to quality and accountability that represents, along with the premiums for malpractice insurance that go with it.  (I assume that pair-programming is not so formal and the original committer is as likely to do the commit as the buddy.)

I can see the code being produced being under an open-source license too. I am failing to grasp how formal RTC can fit with the ASF drive for flat, non-authoritarian structures, though.  I suppose I don't have to understand it, it being unlikely that I would ever be involved in such an arrangement at the ASF.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Reynold Xin <rx...@apache.org>]

Most non-trivial software projects I worked on (paid or un-paid) have RTC
culture. I cannot represent every single project, but in the ones that I'm
closely involved with that use RTC, it is simply part of the culture and
recognition that mandatory code review improves code quality. (We can
debate about this in a separate thread, since this is not what this thread
is about.)


I don't think we should elevate everything to "Apache Way", "trust", or
"community building". RTC vs CTR is not about:

1. Apache Way

Given ASF doesn't require RTC vs CTR vs somewhere in between, and different
TLPs already follow different ways, I don't think any mentor or the
incubator should force their view upon incubating projects.

2. Trust

It's just part of a project's process and culture. Greg brought up that RTC
is an indication of lack of trust and committers are just treated as normal
contributors: "What I haven't seen is an explanation why a committer must
be treated the same as a drive-by. Both are subject to requiring
'permission' to make even the simplest of changes under RTC."

Committers are required to use JIRA, github, and follow many other
processes that "drive-by" should follow. I don't see why "code review" is
different from filing JIRA tickets. In most RTC projects, committers do
have more rights -- a committer can review somebody else's patch and commit
it.

3. community building

Lots of successful open source projects, both inside and outside ASF,
employ RTC. As Todd mentioned, almost all the top 10 most starred (on
github) projects use some form of RTC, so it is hard for me to believe that
RTC would hinder community building. Of course, one can always argue that
if those projects had employed CTR, maybe they would've been even more
popular. But then we got into the area that we just have to agree to
disagree.



On Sun, Nov 22, 2015 at 9:37 PM, Todd Lipcon <to...@cloudera.com> wrote:

> On Sun, Nov 22, 2015 at 12:18 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> >  >
> > > > The question is not to decide if C-T-R is The Apache Way over R-T-C.
> > The
> > > > question is wether a project entering incubation with a selected
> R-T-C
> > > > mode is likely to exit incubation for the simple reason it will be
> very
> > > > hard for this project to grow its community due to this choice. It's
> > > > like starting a 100m race with a 20kb backpack on your shoulder...
> > > >
> > >
> > > If you have any statistics that show this to be the case, I'd be very
> > > interested. RTC is the norm in basically every Apache project I've
> been a
> > > part of, many of which have thriving communities and are generally
> > regarded
> > > as successful software projects.
> >
> > Do you have any statistics on that, Todd? Would be very interesting to
> see,
> > indeed.
> >
> >
> I don't have incubator stats... nor do I have a good way to measure "most
> active" or "most successful" projects in the ASF (seems that itself could
> be a 'centithread'-worthy discussion). But a potential proxy could be the
> number of stars on github:
>
> https://github.com/search?utf8=%E2%9C%93&q=user%3Aapache&type=Repositories&ref=searchresults
>  (sort by number of stars)
>
> Of the top ten:
>
> Spark: RTC via github pull request
> Storm: RTC (https://storm.apache.org/documentation/BYLAWS.html see "Code
> Change")
> Cassandra: RTC (based on my skimming the commit log which has "Reviewed by"
> quite often)
> CouchDB: RTC (http://couchdb.apache.org/bylaws.html see "RTC" section)
> Kafka: RTC (based on "Reviewed by" showing up in recent commit logs)
> Thrift: CTR
> Mesos: RTC (based on reviewboard links in most of the recent commits)
> Zookeeper: RTC (based on personal experience and comments above in this
> thread)
> Cordova: CTR (based on
>
> https://github.com/apache/cordova-coho/blob/master/docs/committer-workflow.md
> )
> Hadoop: RTC (based on personal experience)
>
> Briefly looking through the #11 through #30 projects I also see a
> substantial number which operate on RTC (and others for which I don't know)
>
> So, I don't think there's much evidence that RTC prevents a project from
> becoming successful in the eyes of the developer community. Also worth
> noting that several of these are relatively new TLPs (i.e. within the last
> ~3 years) whereas others are quite old but still active and successful.
>
> -Todd
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Sun, Nov 22, 2015 at 11:37 PM, Todd Lipcon <to...@cloudera.com> wrote:
>...

> I don't have incubator stats... nor do I have a good way to measure "most
> active" or "most successful" projects in the ASF (seems that itself could
> be a 'centithread'-worthy discussion). But a potential proxy could be the
> number of stars on github:
>
>...

> Briefly looking through the #11 through #30 projects I also see a
> substantial number which operate on RTC (and others for which I don't know)
>

Or you could use https://www.openhub.net/orgs/apache which shows exactly
the opposite. GitHub skews based on the tool and the desired RTC workflow,
rather than a bare view of popularity/success.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@cloudera.com>]

On Sun, Nov 22, 2015 at 12:18 PM, Konstantin Boudnik <co...@apache.org> wrote:

>  >
> > > The question is not to decide if C-T-R is The Apache Way over R-T-C.
> The
> > > question is wether a project entering incubation with a selected R-T-C
> > > mode is likely to exit incubation for the simple reason it will be very
> > > hard for this project to grow its community due to this choice. It's
> > > like starting a 100m race with a 20kb backpack on your shoulder...
> > >
> >
> > If you have any statistics that show this to be the case, I'd be very
> > interested. RTC is the norm in basically every Apache project I've been a
> > part of, many of which have thriving communities and are generally
> regarded
> > as successful software projects.
>
> Do you have any statistics on that, Todd? Would be very interesting to see,
> indeed.
>
>
I don't have incubator stats... nor do I have a good way to measure "most
active" or "most successful" projects in the ASF (seems that itself could
be a 'centithread'-worthy discussion). But a potential proxy could be the
number of stars on github:
https://github.com/search?utf8=%E2%9C%93&q=user%3Aapache&type=Repositories&ref=searchresults
 (sort by number of stars)

Of the top ten:

Spark: RTC via github pull request
Storm: RTC (https://storm.apache.org/documentation/BYLAWS.html see "Code
Change")
Cassandra: RTC (based on my skimming the commit log which has "Reviewed by"
quite often)
CouchDB: RTC (http://couchdb.apache.org/bylaws.html see "RTC" section)
Kafka: RTC (based on "Reviewed by" showing up in recent commit logs)
Thrift: CTR
Mesos: RTC (based on reviewboard links in most of the recent commits)
Zookeeper: RTC (based on personal experience and comments above in this
thread)
Cordova: CTR (based on
https://github.com/apache/cordova-coho/blob/master/docs/committer-workflow.md
)
Hadoop: RTC (based on personal experience)

Briefly looking through the #11 through #30 projects I also see a
substantial number which operate on RTC (and others for which I don't know)

So, I don't think there's much evidence that RTC prevents a project from
becoming successful in the eyes of the developer community. Also worth
noting that several of these are relatively new TLPs (i.e. within the last
~3 years) whereas others are quite old but still active and successful.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Wed, Nov 25, 2015 at 9:13 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> And that goes, as always, to the question "Who makes the decision about the
> _right_ level of trust".

The community.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Wed, Nov 25, 2015 at 05:12PM, Chris Douglas wrote:
> RTC is regulation. That's not a synonym for control when it's
> conflated with suspicion of people. Regulation is a set of deliberate
> checks on a system.
> 
> Good regulation estimates (or reacts to) a system's natural excesses,
> then attempts to constrain existential threats. It isn't a lack of
> trust, but how trust is scaled. RTC can encourage review (where

And that goes, as always, to the question "Who makes the decision about the
_right_ level of trust". And, of course, how to make sure the governing body
is corruption-proof. In other words: there are no such thing as 'good
externalized regulation' because sooner or later it gets abused one way or
another. And I dare you to prove me wrong on this ;)

> oversight might be weak), throttle the pace of change (where sheer
> volume might discourage volunteers and exclude individuals), and
> identify code with a discouraging "bus factor" for attention or
> removal (where an isolated contributor can't solicit any feedback).
> Todd, Steve, Andrew, and others already covered other, intended
> desiderata.
> 
> Bad regulation erroneously classifies the power structure as part of
> the system, and threats to powerful people as existential threats to
> the system. It preserves privilege at the expense of individual
> initiative. RTC can mire committers in review, throttle the pace of
> change artificially, and entrench project members behind an inertial
> default. These unintended consequences create new existential threats
> to a project, which either require subsequent regulation/monitoring or
> they prove RTC to be worse than the diseases it remedied.[1]

Supposedly, regulations are introduced as a reaction to failures, if I read
what you're saying correctly. Empirically, majority of the failures in the
self-regulating systems are a result of ill-conceived interventions from the
last time. And we are going into a self-perpetuating cycle where a bad idea
leads to an even worst one and so on, until the system grinds to a halt or
collapse.

And you're right - there are always unintended consequences to artificial
limitations of any sort. One can not create a perfect set of fixed rules to
address all possible future permutations. After all, this is exactly how
the complex dynamic systems work.

In this respect, it is wiser to let the system find the equilibrium by
letting it go, and make small, localized tweaks when/if they needed. In our
case, CTR relies on actors' best judgement with postponed negative feedback if
something goes wrong or deemed incorrect. Such systems prove to be the most
effective when compared with the rigidness of N-pager guidelines document for
every step along the way.

Cos

> In practice, RTC does all these simultaneously, and the community is
> responsible for ensuring the implementation is effective, efficient,
> and just. That balance isn't static, either. One chooses RTC not
> because the code has some property (complexity, size, etc.), but
> because the community does, at the time.
> 
> All that said: many, maybe most projects entering incubation should
> try CTR, and adopt RTC if there's some concrete reason that justifies
> added governance. If the culture requests reviews, enforces tests/CI,
> members can keep up with changes, etc. then most probably won't bother
> with RTC. If the project already has an RTC culture and they want to
> keep it, we've seen that work, too. -C
> 
> 
> [1] RTC/CTR isn't the last policy choice the project makes, either.
> Allowing feature branches to work as CTR (complemented by branch
> committers) can dampen the shortcomings of enforcing RTC on
> trunk/release branches. Policies allowing non-code changes, etc. have
> been mentioned elsewhere in the thread.
> 
> 
> On Wed, Nov 25, 2015 at 12:39 PM, Greg Stein <gs...@gmail.com> wrote:
> > Boo hoo. Todd said it wasn't about control, and then a few days later said
> > he was forcing people into doing reviews. So yeah: in his case, it *is*
> > about control.
> >
> > Over the 17 years I've been around Apache, every single time I've seen
> > somebody attempt to justify something like RTC, it always goes back to
> > control. Always.
> >
> > -g
> >
> >
> > On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell <an...@gmail.com>
> > wrote:
> >
> >> I have to completely disagree and find your assertion vaguely offensive.
> >>
> >> > On Nov 25, 2015, at 12:32 PM, Greg Stein <gs...@gmail.com> wrote:
> >> >
> >> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <ap...@apache.org>
> >> > wrote:
> >> >> ...
> >> >>
> >> >> and inherited the RTC ethic from our parent community. I did recently
> >> test
> >> >> the state of consensus on RTC vs CTR there and it still holds. I think
> >> this
> >> >> model makes sense for HBase, which is a mature (read: complex) code base
> >> >> that implements a distributed database. For sure we want multiple sets
> >> of
> >> >>
> >> >
> >> > I call bullshit. "complex" my ass. I've said it before: all software is
> >> > complex, and yours is no more complex than another. That is NOT a
> >> rationale
> >> > for installing RTC. It is an excuse for maintaining undue control.
> >> >
> >> > -g
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >> For additional commands, e-mail: general-help@incubator.apache.org
> >>
> >>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

I concur. Chris' email is very insightful, and very well written. It is
great food for thought, for each workflow approach.

Thanks, Chris.

... food.. thx... Happy Thanksgiving!
-g
On Nov 26, 2015 4:28 AM, "Steve Loughran" <st...@hortonworks.com> wrote:

>
> This is really good essay on the whole topic. I don't think I've seen a
> post on any asf list which uses both "existential threat" and "desiderata".
> I also like the implication that RTC is a function of the complexity of the
> team, rather than just the code. Every project I've worked on —open or
> closed— had some bit of source that we were all scared of breaking. Those
> bits need their oversight, no matter how —and it's recognition of that need
> that matters more than how the changes are managed.
>
> +1 for encouraging CTR on startup, especially for projects starting out
> with almost no code or people contributing.
>
> > On 26 Nov 2015, at 01:12, Chris Douglas <cd...@apache.org> wrote:
> >
> > RTC is regulation. That's not a synonym for control when it's
> > conflated with suspicion of people. Regulation is a set of deliberate
> > checks on a system.
> >
> > Good regulation estimates (or reacts to) a system's natural excesses,
> > then attempts to constrain existential threats. It isn't a lack of
> > trust, but how trust is scaled. RTC can encourage review (where
> > oversight might be weak), throttle the pace of change (where sheer
> > volume might discourage volunteers and exclude individuals), and
> > identify code with a discouraging "bus factor" for attention or
> > removal (where an isolated contributor can't solicit any feedback).
> > Todd, Steve, Andrew, and others already covered other, intended
> > desiderata.
> >
> > Bad regulation erroneously classifies the power structure as part of
> > the system, and threats to powerful people as existential threats to
> > the system. It preserves privilege at the expense of individual
> > initiative. RTC can mire committers in review, throttle the pace of
> > change artificially, and entrench project members behind an inertial
> > default. These unintended consequences create new existential threats
> > to a project, which either require subsequent regulation/monitoring or
> > they prove RTC to be worse than the diseases it remedied.[1]
> >
> > In practice, RTC does all these simultaneously, and the community is
> > responsible for ensuring the implementation is effective, efficient,
> > and just. That balance isn't static, either. One chooses RTC not
> > because the code has some property (complexity, size, etc.), but
> > because the community does, at the time.
> >
> > All that said: many, maybe most projects entering incubation should
> > try CTR, and adopt RTC if there's some concrete reason that justifies
> > added governance. If the culture requests reviews, enforces tests/CI,
> > members can keep up with changes, etc. then most probably won't bother
> > with RTC. If the project already has an RTC culture and they want to
> > keep it, we've seen that work, too. -C
> >
> >
> > [1] RTC/CTR isn't the last policy choice the project makes, either.
> > Allowing feature branches to work as CTR (complemented by branch
> > committers) can dampen the shortcomings of enforcing RTC on
> > trunk/release branches. Policies allowing non-code changes, etc. have
> > been mentioned elsewhere in the thread.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Steve Loughran <st...@hortonworks.com>]

This is really good essay on the whole topic. I don't think I've seen a post on any asf list which uses both "existential threat" and "desiderata". I also like the implication that RTC is a function of the complexity of the team, rather than just the code. Every project I've worked on —open or closed— had some bit of source that we were all scared of breaking. Those bits need their oversight, no matter how —and it's recognition of that need that matters more than how the changes are managed.

+1 for encouraging CTR on startup, especially for projects starting out with almost no code or people contributing. 

> On 26 Nov 2015, at 01:12, Chris Douglas <cd...@apache.org> wrote:
> 
> RTC is regulation. That's not a synonym for control when it's
> conflated with suspicion of people. Regulation is a set of deliberate
> checks on a system.
> 
> Good regulation estimates (or reacts to) a system's natural excesses,
> then attempts to constrain existential threats. It isn't a lack of
> trust, but how trust is scaled. RTC can encourage review (where
> oversight might be weak), throttle the pace of change (where sheer
> volume might discourage volunteers and exclude individuals), and
> identify code with a discouraging "bus factor" for attention or
> removal (where an isolated contributor can't solicit any feedback).
> Todd, Steve, Andrew, and others already covered other, intended
> desiderata.
> 
> Bad regulation erroneously classifies the power structure as part of
> the system, and threats to powerful people as existential threats to
> the system. It preserves privilege at the expense of individual
> initiative. RTC can mire committers in review, throttle the pace of
> change artificially, and entrench project members behind an inertial
> default. These unintended consequences create new existential threats
> to a project, which either require subsequent regulation/monitoring or
> they prove RTC to be worse than the diseases it remedied.[1]
> 
> In practice, RTC does all these simultaneously, and the community is
> responsible for ensuring the implementation is effective, efficient,
> and just. That balance isn't static, either. One chooses RTC not
> because the code has some property (complexity, size, etc.), but
> because the community does, at the time.
> 
> All that said: many, maybe most projects entering incubation should
> try CTR, and adopt RTC if there's some concrete reason that justifies
> added governance. If the culture requests reviews, enforces tests/CI,
> members can keep up with changes, etc. then most probably won't bother
> with RTC. If the project already has an RTC culture and they want to
> keep it, we've seen that work, too. -C
> 
> 
> [1] RTC/CTR isn't the last policy choice the project makes, either.
> Allowing feature branches to work as CTR (complemented by branch
> committers) can dampen the shortcomings of enforcing RTC on
> trunk/release branches. Policies allowing non-code changes, etc. have
> been mentioned elsewhere in the thread.
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Chris Douglas <cd...@apache.org>]

RTC is regulation. That's not a synonym for control when it's
conflated with suspicion of people. Regulation is a set of deliberate
checks on a system.

Good regulation estimates (or reacts to) a system's natural excesses,
then attempts to constrain existential threats. It isn't a lack of
trust, but how trust is scaled. RTC can encourage review (where
oversight might be weak), throttle the pace of change (where sheer
volume might discourage volunteers and exclude individuals), and
identify code with a discouraging "bus factor" for attention or
removal (where an isolated contributor can't solicit any feedback).
Todd, Steve, Andrew, and others already covered other, intended
desiderata.

Bad regulation erroneously classifies the power structure as part of
the system, and threats to powerful people as existential threats to
the system. It preserves privilege at the expense of individual
initiative. RTC can mire committers in review, throttle the pace of
change artificially, and entrench project members behind an inertial
default. These unintended consequences create new existential threats
to a project, which either require subsequent regulation/monitoring or
they prove RTC to be worse than the diseases it remedied.[1]

In practice, RTC does all these simultaneously, and the community is
responsible for ensuring the implementation is effective, efficient,
and just. That balance isn't static, either. One chooses RTC not
because the code has some property (complexity, size, etc.), but
because the community does, at the time.

All that said: many, maybe most projects entering incubation should
try CTR, and adopt RTC if there's some concrete reason that justifies
added governance. If the culture requests reviews, enforces tests/CI,
members can keep up with changes, etc. then most probably won't bother
with RTC. If the project already has an RTC culture and they want to
keep it, we've seen that work, too. -C


[1] RTC/CTR isn't the last policy choice the project makes, either.
Allowing feature branches to work as CTR (complemented by branch
committers) can dampen the shortcomings of enforcing RTC on
trunk/release branches. Policies allowing non-code changes, etc. have
been mentioned elsewhere in the thread.


On Wed, Nov 25, 2015 at 12:39 PM, Greg Stein <gs...@gmail.com> wrote:
> Boo hoo. Todd said it wasn't about control, and then a few days later said
> he was forcing people into doing reviews. So yeah: in his case, it *is*
> about control.
>
> Over the 17 years I've been around Apache, every single time I've seen
> somebody attempt to justify something like RTC, it always goes back to
> control. Always.
>
> -g
>
>
> On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell <an...@gmail.com>
> wrote:
>
>> I have to completely disagree and find your assertion vaguely offensive.
>>
>> > On Nov 25, 2015, at 12:32 PM, Greg Stein <gs...@gmail.com> wrote:
>> >
>> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <ap...@apache.org>
>> > wrote:
>> >> ...
>> >>
>> >> and inherited the RTC ethic from our parent community. I did recently
>> test
>> >> the state of consensus on RTC vs CTR there and it still holds. I think
>> this
>> >> model makes sense for HBase, which is a mature (read: complex) code base
>> >> that implements a distributed database. For sure we want multiple sets
>> of
>> >>
>> >
>> > I call bullshit. "complex" my ass. I've said it before: all software is
>> > complex, and yours is no more complex than another. That is NOT a
>> rationale
>> > for installing RTC. It is an excuse for maintaining undue control.
>> >
>> > -g
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell <an...@gmail.com>]

And I challenge you to comb over all HBase mailing lists and JIRAs and find any instance where we were not the model of a meritocratic and consensus driven community, or any instance where a committer has ever been aggrieved by our practices, and especially where I as chair have tried to exert control. It's harder to impugn people's motives if there's at least a minimal evidentiary bar. 


> On Nov 25, 2015, at 12:39 PM, Greg Stein <gs...@gmail.com> wrote:
> 
> Boo hoo. Todd said it wasn't about control, and then a few days later said
> he was forcing people into doing reviews. So yeah: in his case, it *is*
> about control.
> 
> Over the 17 years I've been around Apache, every single time I've seen
> somebody attempt to justify something like RTC, it always goes back to
> control. Always.
> 
> -g
> 
> 
> On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell <an...@gmail.com>
> wrote:
> 
>> I have to completely disagree and find your assertion vaguely offensive.
>> 
>>> On Nov 25, 2015, at 12:32 PM, Greg Stein <gs...@gmail.com> wrote:
>>> 
>>> On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <ap...@apache.org>
>>> wrote:
>>>> ...
>>>> 
>>>> and inherited the RTC ethic from our parent community. I did recently
>> test
>>>> the state of consensus on RTC vs CTR there and it still holds. I think
>> this
>>>> model makes sense for HBase, which is a mature (read: complex) code base
>>>> that implements a distributed database. For sure we want multiple sets
>> of
>>> 
>>> I call bullshit. "complex" my ass. I've said it before: all software is
>>> complex, and yours is no more complex than another. That is NOT a
>> rationale
>>> for installing RTC. It is an excuse for maintaining undue control.
>>> 
>>> -g
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>> 
>> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Thu, Nov 26, 2015 at 10:56 AM, Harbs <ha...@gmail.com> wrote:
>...

> So technically, the review is after the commit (to a central staging
> repo), but it’s mandatory before the commit is officially accepted and will
> be checked out from the (central approved) repo. It’s an interesting
> approach.
>
> (I realize that some folks will still consider this “bad”, but I can see
> why it might be attractive.)
>

Yup. It is a great tool once you've decided to go with RTC. Same with
GitHub Pull Requests.

IMO, it is the *tooling* around Git which makes it great. As a VCS, it is
fine, but it shines when matched with the tool ecosystem. You could do
pretty much all this with svn, but nobody ever built the tooling. :-/
 svn's strengths lie elsewhere.

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Harbs <ha...@gmail.com>]

FWIW:

I just now looked at Gerrit (being it’s what sparked this discussion) and I think that it falls in that category between classic CTR and RTC. I was reading this document which gives an overview.[1] The review there happens IN the central repo, but it’s mandatory before content is checked out. I assume the technology uses two repos internally which is an “pending” repo as well as an “approved” one but I could be wrong on that. (I only gave it a quick one-over.)

So technically, the review is after the commit (to a central staging repo), but it’s mandatory before the commit is officially accepted and will be checked out from the (central approved) repo. It’s an interesting approach.

(I realize that some folks will still consider this “bad”, but I can see why it might be attractive.)

Harbs

https://gerrit-review.googlesource.com/Documentation/intro-quick.html
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Joe Schaefer <jo...@gmail.com>]

This saga jumped the shark right about the time Mary the sonnetor weighted
in.

On Thursday, November 26, 2015, Ralph Goers <ra...@dslextreme.com>
wrote:

> Sorry Jim. As an attempt to shut down a thread, this wasn't a very good
> one.  Not a single poster in this thread has a problem with the word, or
> the concept of, "review". It is the process that is the issue and what the
> impact of that process is upon a community.
>
> Ralph
>
> > On Nov 26, 2015, at 6:50 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> >
> > OK, ok... we are at diminishing returns here with people
> > no longer, imo, listening to what others are saying...
> >
> > We have, as a foundation, and HAVE HAD RTC and CTR for years
> > and decades. There are times when one or the other are Good
> > and when they are Bad. Those exact times will, generally,
> > vary depending on a lot of factors.
> >
> > We use the right process when it is Good.
> >
> > We don't use it when it is Bad.
> >
> > Just as 'meritocracy' is not a bad word, as much as
> > some people wish to re-define it as such, neither is the
> > word 'Review'.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> > For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers <ra...@dslextreme.com>]

Sorry Jim. As an attempt to shut down a thread, this wasn't a very good one.  Not a single poster in this thread has a problem with the word, or the concept of, "review". It is the process that is the issue and what the impact of that process is upon a community.

Ralph

> On Nov 26, 2015, at 6:50 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> 
> OK, ok... we are at diminishing returns here with people
> no longer, imo, listening to what others are saying...
> 
> We have, as a foundation, and HAVE HAD RTC and CTR for years
> and decades. There are times when one or the other are Good
> and when they are Bad. Those exact times will, generally,
> vary depending on a lot of factors.
> 
> We use the right process when it is Good.
> 
> We don't use it when it is Bad.
> 
> Just as 'meritocracy' is not a bad word, as much as
> some people wish to re-define it as such, neither is the
> word 'Review'. 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Jim Jagielski <ji...@jaguNET.com>]

OK, ok... we are at diminishing returns here with people
no longer, imo, listening to what others are saying...

We have, as a foundation, and HAVE HAD RTC and CTR for years
and decades. There are times when one or the other are Good
and when they are Bad. Those exact times will, generally,
vary depending on a lot of factors.

We use the right process when it is Good.

We don't use it when it is Bad.

Just as 'meritocracy' is not a bad word, as much as
some people wish to re-define it as such, neither is the
word 'Review'. 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Pierre Smits <pi...@gmail.com>]

I see some are trying to spread quite some FUD.

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Wed, Nov 25, 2015 at 11:47 PM, Sam Ruby <ru...@intertwingly.net> wrote:

> On Wed, Nov 25, 2015 at 5:18 PM, Greg Stein <gs...@gmail.com> wrote:
> > On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby <ru...@intertwingly.net>
> wrote:
> >
> >> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein <gs...@gmail.com> wrote:
> >> >
> >> > Don't shut down trunk/master for product development.
> >>
> >> I don't believe you heard my point, but I'm not going to repeat it.
> >
> > I read your post several times, completely :-P ... I just think it didn't
> > argue against RTC being a form on control. (and yeah, maybe you weren't
> > trying to argue that?)
>
> I don't believe that RTC is a form of control over others.  I believe
> that RTC is a mechanism to ensure that every change is adequately
> reviewed.
>
> >> Instead I will add a new point.
> >>
> >> 'trunk/master for product development' is not the only development
> >> model available to a project.  As an example, I've seen models where
> >> 'trunk/master is for product maintenance', and all development occurs
> >> in a branch explicitly designated as where work on the next release is
> >> to occur.
> >>
> >
> > I think that is just playing with names. In Apache Subversion the
> "product
> > maintenance" is branches/1.8.x and branches/1.9.x (1.7.x and prior are
> > deprecated). trunk is for "next release".
> >
> > In your naming model, where we've seen the name "develop" for "next
> > release" (aka where all new dev occurs), then I'd say making it RTC is
> > harmful.
> >
> > trunk/master was shorthand for "where dev occurs". If you want to use a
> > different name... okay. :-)
>
> I don't believe it is just playing with names.  There are projects in
> when all non-trivial development occurs in feature branches.
>
> > Cheers,
> > -g
> >
> > ps. fwiw, trunk/tags/branches isn't mandated in svn either. It was just
> an
> > ad hoc template we came up with back near the start of the project. We
> > assumed third-party tools would focus around that naming, which is
> > generally true, but svn itself has never cared.
>
> Ack.
>
> - Sam Ruby
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Wed, Nov 25, 2015 at 5:18 PM, Greg Stein <gs...@gmail.com> wrote:
> On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein <gs...@gmail.com> wrote:
>> >
>> > Don't shut down trunk/master for product development.
>>
>> I don't believe you heard my point, but I'm not going to repeat it.
>
> I read your post several times, completely :-P ... I just think it didn't
> argue against RTC being a form on control. (and yeah, maybe you weren't
> trying to argue that?)

I don't believe that RTC is a form of control over others.  I believe
that RTC is a mechanism to ensure that every change is adequately
reviewed.

>> Instead I will add a new point.
>>
>> 'trunk/master for product development' is not the only development
>> model available to a project.  As an example, I've seen models where
>> 'trunk/master is for product maintenance', and all development occurs
>> in a branch explicitly designated as where work on the next release is
>> to occur.
>>
>
> I think that is just playing with names. In Apache Subversion the "product
> maintenance" is branches/1.8.x and branches/1.9.x (1.7.x and prior are
> deprecated). trunk is for "next release".
>
> In your naming model, where we've seen the name "develop" for "next
> release" (aka where all new dev occurs), then I'd say making it RTC is
> harmful.
>
> trunk/master was shorthand for "where dev occurs". If you want to use a
> different name... okay. :-)

I don't believe it is just playing with names.  There are projects in
when all non-trivial development occurs in feature branches.

> Cheers,
> -g
>
> ps. fwiw, trunk/tags/branches isn't mandated in svn either. It was just an
> ad hoc template we came up with back near the start of the project. We
> assumed third-party tools would focus around that naming, which is
> generally true, but svn itself has never cared.

Ack.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby <ru...@intertwingly.net> wrote:

> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > Don't shut down trunk/master for product development.
>
> I don't believe you heard my point, but I'm not going to repeat it.
>

I read your post several times, completely :-P ... I just think it didn't
argue against RTC being a form on control. (and yeah, maybe you weren't
trying to argue that?)


> Instead I will add a new point.
>
> 'trunk/master for product development' is not the only development
> model available to a project.  As an example, I've seen models where
> 'trunk/master is for product maintenance', and all development occurs
> in a branch explicitly designated as where work on the next release is
> to occur.
>

I think that is just playing with names. In Apache Subversion the "product
maintenance" is branches/1.8.x and branches/1.9.x (1.7.x and prior are
deprecated). trunk is for "next release".

In your naming model, where we've seen the name "develop" for "next
release" (aka where all new dev occurs), then I'd say making it RTC is
harmful.

trunk/master was shorthand for "where dev occurs". If you want to use a
different name... okay. :-)

Cheers,
-g

ps. fwiw, trunk/tags/branches isn't mandated in svn either. It was just an
ad hoc template we came up with back near the start of the project. We
assumed third-party tools would focus around that naming, which is
generally true, but svn itself has never cared.

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein <gs...@gmail.com> wrote:
>
> Don't shut down trunk/master for product development.

I don't believe you heard my point, but I'm not going to repeat it.
Instead I will add a new point.

'trunk/master for product development' is not the only development
model available to a project.  As an example, I've seen models where
'trunk/master is for product maintenance', and all development occurs
in a branch explicitly designated as where work on the next release is
to occur.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Wed, Nov 25, 2015 at 3:27 PM, Sam Ruby <ru...@intertwingly.net> wrote:

> On Wed, Nov 25, 2015 at 3:39 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > Over the 17 years I've been around Apache, every single time I've seen
> > somebody attempt to justify something like RTC, it always goes back to
> > control. Always.
>
> Strongly disagree.  If you say 'every', all it takes is one counter
> example to disprove the assertion.  Here is a counter example:
>
>
> https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo
>
> It is not a hypothetical example from the distant past.  It is a live
> example which seems to work well.  I've witnessed it being used for
> single line patches (a removal of a line, in fact) in a YAML file.
> Gavin created a branch, made a patch, pushed it, and Daniel merged it.
> Not for provenance reasons.  Or for control reasons.  But to ensure a
> second set of eyes looked at the change and evaluated whether or not
> there may be some unanticipated side effect.
>

I disagree. It *is* for control reasons. Infra can't allow a patch to be
deployed willy-nilly, or shit goes wrong. Fast.

Infra is not building a software product. They are maintaining live
systems. Control is absolutely needed.

Their entire repository is like a release stabilization branch. It needs to
be vetted before release.

I'll propose a thought experiment.  We seem to agree that there is
> room for teams to impose some form of RTC on branches that are to be
> released "soonish" (for some value of "soonish").  Let's take the next
>

Yes, I call those branches "owned by" or "personal branch of" the RM, who
decides to apply his/her rules on what is allowed onto the branch. At some
point, the RM cuts a release and the community votes on it.

One RM might allow any change. Another RM might require (3) +1 votes for
any change to be applied. Yet another refuses all change, and only applies
changes themselves.

step... what happens if releases are frequent (i.e. approaching
> continuous?).
>

Don't shut down trunk/master for product development. If the RMs want to
push my work into the releases each week, then great. I'll help them, under
the rules they set. If I find their release rules too onerous, then I'll
start my own release under Apache's "any committer can be an RM" and hope
for (3) +1 votes on the result.


> That's essentially what the infrastructure team is faced with.
>

It's not a product. They are solving a very different problem.

>...

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Wed, Nov 25, 2015 at 3:39 PM, Greg Stein <gs...@gmail.com> wrote:
>
> Over the 17 years I've been around Apache, every single time I've seen
> somebody attempt to justify something like RTC, it always goes back to
> control. Always.

Strongly disagree.  If you say 'every', all it takes is one counter
example to disprove the assertion.  Here is a counter example:

https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo

It is not a hypothetical example from the distant past.  It is a live
example which seems to work well.  I've witnessed it being used for
single line patches (a removal of a line, in fact) in a YAML file.
Gavin created a branch, made a patch, pushed it, and Daniel merged it.
Not for provenance reasons.  Or for control reasons.  But to ensure a
second set of eyes looked at the change and evaluated whether or not
there may be some unanticipated side effect.

I'll propose a thought experiment.  We seem to agree that there is
room for teams to impose some form of RTC on branches that are to be
released "soonish" (for some value of "soonish").  Let's take the next
step... what happens if releases are frequent (i.e. approaching
continuous?).

That's essentially what the infrastructure team is faced with.

I don't give a whit about 'control issues' (perceived or real, doesn't
matter).  Anything I commit may be reverted.  I'm fine with that.  I
don't presume to control anything.  And if somebody wants to try to
control me -- all I can say is: good luck with that.  :-P

What I care most about is languishing patches.  Whether they come from
team members or drive by contributors, doesn't matter.  That's
harmful.  Git, and in particular, GitHub, makes them less harmful, but
they are the root problem not whether the process is
Commit-Then-Revert or Post-Then-Ignore.

If most communities in the Hadoop ecosystem use RTC, I don't care
UNLESS there is evidence of them not being responsive to patches.  For
quieter communities (including apparently BigTop), RTC could lead to
problems, and CTR is arguably more appropriate.  I'm fine with that
too.

- Sam Ruby

P.S.  My personal preference remains CTR.  I would much rather be
reverted with an explanation than to be ignored without one.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

Boo hoo. Todd said it wasn't about control, and then a few days later said
he was forcing people into doing reviews. So yeah: in his case, it *is*
about control.

Over the 17 years I've been around Apache, every single time I've seen
somebody attempt to justify something like RTC, it always goes back to
control. Always.

-g


On Wed, Nov 25, 2015 at 2:35 PM, Andrew Purtell <an...@gmail.com>
wrote:

> I have to completely disagree and find your assertion vaguely offensive.
>
> > On Nov 25, 2015, at 12:32 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >> ...
> >>
> >> and inherited the RTC ethic from our parent community. I did recently
> test
> >> the state of consensus on RTC vs CTR there and it still holds. I think
> this
> >> model makes sense for HBase, which is a mature (read: complex) code base
> >> that implements a distributed database. For sure we want multiple sets
> of
> >>
> >
> > I call bullshit. "complex" my ass. I've said it before: all software is
> > complex, and yours is no more complex than another. That is NOT a
> rationale
> > for installing RTC. It is an excuse for maintaining undue control.
> >
> > -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell <an...@gmail.com>]

I have to completely disagree and find your assertion vaguely offensive. 

> On Nov 25, 2015, at 12:32 PM, Greg Stein <gs...@gmail.com> wrote:
> 
> On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <ap...@apache.org>
> wrote:
>> ...
>> 
>> and inherited the RTC ethic from our parent community. I did recently test
>> the state of consensus on RTC vs CTR there and it still holds. I think this
>> model makes sense for HBase, which is a mature (read: complex) code base
>> that implements a distributed database. For sure we want multiple sets of
>> 
> 
> I call bullshit. "complex" my ass. I've said it before: all software is
> complex, and yours is no more complex than another. That is NOT a rationale
> for installing RTC. It is an excuse for maintaining undue control.
> 
> -g

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell <ap...@apache.org>
wrote:
>...
>
> and inherited the RTC ethic from our parent community. I did recently test
> the state of consensus on RTC vs CTR there and it still holds. I think this
> model makes sense for HBase, which is a mature (read: complex) code base
> that implements a distributed database. For sure we want multiple sets of
>

I call bullshit. "complex" my ass. I've said it before: all software is
complex, and yours is no more complex than another. That is NOT a rationale
for installing RTC. It is an excuse for maintaining undue control.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell <ap...@apache.org>]

Most of the Hadoop ecosystem uses RTC. I can't speak to other projects but
on the one I chair there's no conspiracy to exclude anyone.

I chair Bigtop. We recently tested a switch to CTR. It went very well and
so we just wrapped up a vote to make it the permanent state of affairs. I
think this is the best option for Bigtop, which has a small but active
group of committers each working in loosely coupled ways on different parts
of the tree. I also chair HBase. We were spun out of Hadoop direct to TLP
and inherited the RTC ethic from our parent community. I did recently test
the state of consensus on RTC vs CTR there and it still holds. I think this
model makes sense for HBase, which is a mature (read: complex) code base
that implements a distributed database. For sure we want multiple sets of
eyes on changes there. They can have unexpected consequences. Almost above
all, we want to do due diligence on not introducing bugs that lose user
data.

So, to each their own? Please.




On Sun, Nov 22, 2015 at 2:05 PM, Ralph Goers <ra...@dslextreme.com>
wrote:

> Yes, it would be good to take a survey.  Interestingly, I wasn’t aware
> that ANY Apache projects used RTC until I became involved with a project in
> the Hadoop ecosystem, which seems to align with Tood’s statement since all
> the projects he is listed as being involved in are part of that.  In fact,
> when I was mentoring the project I am familiar with I asked during
> incubation why they wanted to use RTC and was told that it was because that
> is the way all Hadoop related projects worked. Since most of the committers
> were paid to work on the project by their employer I also got the feeling
> that it aligned with that.
>
> Ralph
>
> > On Nov 22, 2015, at 1:18 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> >> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <
> elecharny@gmail.com>
> >> wrote:
> >>>
> >>>>>
> >>>> Except that there seems to be great disagreement among the Members as
> to
> >>>> whether RTC is somehow anti-Apache-Way.
> >>>>
> >>>> If you want to try to create an ASF-wide resolution that RTC doesn't
> >>> follow
> >>>> the Apache Way, and get the board/membership to vote on it, go ahead,
> but
> >>>> it confuses podlings who are new to the ASF when people espouse
> personal
> >>>> opinions as if they are ASF rules.
> >>>
> >>> That is not the point.
> >>>
> >>>
> >>> The question is not to decide if C-T-R is The Apache Way over R-T-C.
> The
> >>> question is wether a project entering incubation with a selected R-T-C
> >>> mode is likely to exit incubation for the simple reason it will be very
> >>> hard for this project to grow its community due to this choice. It's
> >>> like starting a 100m race with a 20kb backpack on your shoulder...
> >>>
> >>
> >> If you have any statistics that show this to be the case, I'd be very
> >> interested. RTC is the norm in basically every Apache project I've been
> a
> >> part of, many of which have thriving communities and are generally
> regarded
> >> as successful software projects.
> >
> > Do you have any statistics on that, Todd? Would be very interesting to
> see,
> > indeed.
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>


-- 
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Re: RTC vs CTR (was: Concerning Sentry...)

[Henry Saputra <he...@gmail.com>]

I second that. Most Hadoop related projects have this strict RTC policy,
so committers from those projects try to implement it to other
projects they are involve with.


On Sunday, November 22, 2015, Ralph Goers <ra...@dslextreme.com>
wrote:

> Yes, it would be good to take a survey.  Interestingly, I wasn’t aware
> that ANY Apache projects used RTC until I became involved with a project in
> the Hadoop ecosystem, which seems to align with Tood’s statement since all
> the projects he is listed as being involved in are part of that.  In fact,
> when I was mentoring the project I am familiar with I asked during
> incubation why they wanted to use RTC and was told that it was because that
> is the way all Hadoop related projects worked. Since most of the committers
> were paid to work on the project by their employer I also got the feeling
> that it aligned with that.
>
> Ralph
>
> > On Nov 22, 2015, at 1:18 PM, Konstantin Boudnik <cos@apache.org
> <javascript:;>> wrote:
> >
> > On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> >> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <
> elecharny@gmail.com <javascript:;>>
> >> wrote:
> >>>
> >>>>>
> >>>> Except that there seems to be great disagreement among the Members as
> to
> >>>> whether RTC is somehow anti-Apache-Way.
> >>>>
> >>>> If you want to try to create an ASF-wide resolution that RTC doesn't
> >>> follow
> >>>> the Apache Way, and get the board/membership to vote on it, go ahead,
> but
> >>>> it confuses podlings who are new to the ASF when people espouse
> personal
> >>>> opinions as if they are ASF rules.
> >>>
> >>> That is not the point.
> >>>
> >>>
> >>> The question is not to decide if C-T-R is The Apache Way over R-T-C.
> The
> >>> question is wether a project entering incubation with a selected R-T-C
> >>> mode is likely to exit incubation for the simple reason it will be very
> >>> hard for this project to grow its community due to this choice. It's
> >>> like starting a 100m race with a 20kb backpack on your shoulder...
> >>>
> >>
> >> If you have any statistics that show this to be the case, I'd be very
> >> interested. RTC is the norm in basically every Apache project I've been
> a
> >> part of, many of which have thriving communities and are generally
> regarded
> >> as successful software projects.
> >
> > Do you have any statistics on that, Todd? Would be very interesting to
> see,
> > indeed.
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers <ra...@dslextreme.com>]

Yes, it would be good to take a survey.  Interestingly, I wasn’t aware that ANY Apache projects used RTC until I became involved with a project in the Hadoop ecosystem, which seems to align with Tood’s statement since all the projects he is listed as being involved in are part of that.  In fact, when I was mentoring the project I am familiar with I asked during incubation why they wanted to use RTC and was told that it was because that is the way all Hadoop related projects worked. Since most of the committers were paid to work on the project by their employer I also got the feeling that it aligned with that.

Ralph

> On Nov 22, 2015, at 1:18 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
>> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <el...@gmail.com>
>> wrote:
>>> 
>>>>> 
>>>> Except that there seems to be great disagreement among the Members as to
>>>> whether RTC is somehow anti-Apache-Way.
>>>> 
>>>> If you want to try to create an ASF-wide resolution that RTC doesn't
>>> follow
>>>> the Apache Way, and get the board/membership to vote on it, go ahead, but
>>>> it confuses podlings who are new to the ASF when people espouse personal
>>>> opinions as if they are ASF rules.
>>> 
>>> That is not the point.
>>> 
>>> 
>>> The question is not to decide if C-T-R is The Apache Way over R-T-C. The
>>> question is wether a project entering incubation with a selected R-T-C
>>> mode is likely to exit incubation for the simple reason it will be very
>>> hard for this project to grow its community due to this choice. It's
>>> like starting a 100m race with a 20kb backpack on your shoulder...
>>> 
>> 
>> If you have any statistics that show this to be the case, I'd be very
>> interested. RTC is the norm in basically every Apache project I've been a
>> part of, many of which have thriving communities and are generally regarded
>> as successful software projects.
> 
> Do you have any statistics on that, Todd? Would be very interesting to see,
> indeed.
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
> >
> > >>
> > > Except that there seems to be great disagreement among the Members as to
> > > whether RTC is somehow anti-Apache-Way.
> > >
> > > If you want to try to create an ASF-wide resolution that RTC doesn't
> > follow
> > > the Apache Way, and get the board/membership to vote on it, go ahead, but
> > > it confuses podlings who are new to the ASF when people espouse personal
> > > opinions as if they are ASF rules.
> >
> > That is not the point.
> >
> >
> > The question is not to decide if C-T-R is The Apache Way over R-T-C. The
> > question is wether a project entering incubation with a selected R-T-C
> > mode is likely to exit incubation for the simple reason it will be very
> > hard for this project to grow its community due to this choice. It's
> > like starting a 100m race with a 20kb backpack on your shoulder...
> >
> 
> If you have any statistics that show this to be the case, I'd be very
> interested. RTC is the norm in basically every Apache project I've been a
> part of, many of which have thriving communities and are generally regarded
> as successful software projects.

Do you have any statistics on that, Todd? Would be very interesting to see,
indeed.

Re: RTC vs CTR (was: Concerning Sentry...)

[Emmanuel Lécharny <el...@gmail.com>]

Le 18/11/15 08:12, Todd Lipcon a écrit :
> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>>> Except that there seems to be great disagreement among the Members as to
>>> whether RTC is somehow anti-Apache-Way.
>>>
>>> If you want to try to create an ASF-wide resolution that RTC doesn't
>> follow
>>> the Apache Way, and get the board/membership to vote on it, go ahead, but
>>> it confuses podlings who are new to the ASF when people espouse personal
>>> opinions as if they are ASF rules.
>> That is not the point.
>>
>>
>> The question is not to decide if C-T-R is The Apache Way over R-T-C. The
>> question is wether a project entering incubation with a selected R-T-C
>> mode is likely to exit incubation for the simple reason it will be very
>> hard for this project to grow its community due to this choice. It's
>> like starting a 100m race with a 20kb backpack on your shoulder...
>>
> If you have any statistics that show this to be the case, I'd be very
> interested. RTC is the norm in basically every Apache project I've been a
> part of, many of which have thriving communities and are generally regarded
> as successful software projects.

I don't have stats. I don't know a lot of Apache Projects using R-T-C,
and the 5 incubating projects I have mentored haven't even mentionned
the matter at all : it was C-T-R from day zero for them.

I would be *very* surprised if more than a few Apache projects were to
use R-T-C mode...

And again, it's not really important here. The key is to know if you
want the project to be out of incubator quickly. From the community
building POV, I just think that using R-T-C will make the path way
longer... If you think it's not a problem, then fine.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@cloudera.com>]

On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
>
> >>
> > Except that there seems to be great disagreement among the Members as to
> > whether RTC is somehow anti-Apache-Way.
> >
> > If you want to try to create an ASF-wide resolution that RTC doesn't
> follow
> > the Apache Way, and get the board/membership to vote on it, go ahead, but
> > it confuses podlings who are new to the ASF when people espouse personal
> > opinions as if they are ASF rules.
>
> That is not the point.
>
>
> The question is not to decide if C-T-R is The Apache Way over R-T-C. The
> question is wether a project entering incubation with a selected R-T-C
> mode is likely to exit incubation for the simple reason it will be very
> hard for this project to grow its community due to this choice. It's
> like starting a 100m race with a 20kb backpack on your shoulder...
>

If you have any statistics that show this to be the case, I'd be very
interested. RTC is the norm in basically every Apache project I've been a
part of, many of which have thriving communities and are generally regarded
as successful software projects.

Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Emmanuel Lécharny <el...@gmail.com>]

Le 18/11/15 03:06, Todd Lipcon a écrit :
> On Tue, Nov 17, 2015 at 5:57 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
>> On the contrary... The business of the Incubator and IPMC is to help
>> podlings
>> and their communities to grok and follow the Apache Way. Trust is a
>> foundation
>> principal of a healthy community. Hence, this whole discussion has quite a
>> lot
>> of business in the incubator.
>>
> Except that there seems to be great disagreement among the Members as to
> whether RTC is somehow anti-Apache-Way.
>
> If you want to try to create an ASF-wide resolution that RTC doesn't follow
> the Apache Way, and get the board/membership to vote on it, go ahead, but
> it confuses podlings who are new to the ASF when people espouse personal
> opinions as if they are ASF rules.

That is not the point.


The question is not to decide if C-T-R is The Apache Way over R-T-C. The
question is wether a project entering incubation with a selected R-T-C
mode is likely to exit incubation for the simple reason it will be very
hard for this project to grow its community due to this choice. It's
like starting a 100m race with a 20kb backpack on your shoulder...



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 17, 2015 at 8:06 PM, Todd Lipcon <to...@apache.org> wrote:
>...

> Except that there seems to be great disagreement among the Members as to
> whether RTC is somehow anti-Apache-Way.
>

That seems rather melodramatic. Speaking for myself, I've said that I find
RTC a terrible basis for forming a healthy community. I never mentioned the
Apache Way.


> If you want to try to create an ASF-wide resolution that RTC doesn't follow
> the Apache Way, and get the board/membership to vote on it, go ahead, but
> it confuses podlings who are new to the ASF when people espouse personal
> opinions as if they are ASF rules.
>

And again with the drama: nobody has suggested imposing any particular
approach on Apache communities.

I responded in this thread (and others) to get my views "out there", so
that podlings and other Apache communities can review my reasoning, and
whether those thoughts could be applied within their community.

Cheers,
-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Tue, Nov 17, 2015 at 06:06PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 5:57 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> >
> > On the contrary... The business of the Incubator and IPMC is to help
> > podlings
> > and their communities to grok and follow the Apache Way. Trust is a
> > foundation
> > principal of a healthy community. Hence, this whole discussion has quite a
> > lot
> > of business in the incubator.
> >
> 
> Except that there seems to be great disagreement among the Members as to
> whether RTC is somehow anti-Apache-Way.

Woot?

> If you want to try to create an ASF-wide resolution that RTC doesn't follow
> the Apache Way, and get the board/membership to vote on it, go ahead, but

Thanks, I will thing about this idea.

> it confuses podlings who are new to the ASF when people espouse personal
> opinions as if they are ASF rules.
> 
> -Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@apache.org>]

On Tue, Nov 17, 2015 at 5:57 PM, Konstantin Boudnik <co...@apache.org> wrote:

>
> On the contrary... The business of the Incubator and IPMC is to help
> podlings
> and their communities to grok and follow the Apache Way. Trust is a
> foundation
> principal of a healthy community. Hence, this whole discussion has quite a
> lot
> of business in the incubator.
>

Except that there seems to be great disagreement among the Members as to
whether RTC is somehow anti-Apache-Way.

If you want to try to create an ASF-wide resolution that RTC doesn't follow
the Apache Way, and get the board/membership to vote on it, go ahead, but
it confuses podlings who are new to the ASF when people espouse personal
opinions as if they are ASF rules.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Tue, Nov 17, 2015 at 04:45PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 4:37 PM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> > > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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".
> >
> > This sounds like "if I don't trust myself then no-one has to have this
> > freedom/choice/ability", eh?
> >
> 
> I'd never advocate that the ASF _mandate_ RTC on other projects. But if a
> project community decides to set up their process as such, I don't see why
> the foundation should have any issues with it. That's all I've been arguing
> in this thread: this whole discussion has pretty much no business in the
> incubator.

On the contrary... The business of the Incubator and IPMC is to help podlings
and their communities to grok and follow the Apache Way. Trust is a foundation
principal of a healthy community. Hence, this whole discussion has quite a lot
of business in the incubator.

Cos

Re: RTC vs CTR (was: Concerning Sentry...)

[Joe Schaefer <jo...@gmail.com>]

Completely agreed Todd about the irrelevance of these ad hoc assessments
of something nobody actually questions.

On Tue, Nov 17, 2015 at 7:45 PM, Todd Lipcon <to...@apache.org> wrote:

> On Tue, Nov 17, 2015 at 4:37 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
>
> > On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> > > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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".
> >
> > This sounds like "if I don't trust myself then no-one has to have this
> > freedom/choice/ability", eh?
> >
>
> I'd never advocate that the ASF _mandate_ RTC on other projects. But if a
> project community decides to set up their process as such, I don't see why
> the foundation should have any issues with it. That's all I've been arguing
> in this thread: this whole discussion has pretty much no business in the
> incubator.
>
> -Todd
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@apache.org>]

On Tue, Nov 17, 2015 at 4:37 PM, Konstantin Boudnik <co...@apache.org> wrote:

> On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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".
>
> This sounds like "if I don't trust myself then no-one has to have this
> freedom/choice/ability", eh?
>

I'd never advocate that the ASF _mandate_ RTC on other projects. But if a
project community decides to set up their process as such, I don't see why
the foundation should have any issues with it. That's all I've been arguing
in this thread: this whole discussion has pretty much no business in the
incubator.

-Todd

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Tue, Nov 17, 2015 at 08:53AM, Bertrand Delacretaz wrote:
> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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".

This sounds like "if I don't trust myself then no-one has to have this
freedom/choice/ability", eh?

> Like all sharp tools I think RTC has its place, but shouldn't be
> abused. It's perfectly possible to have some parts of a project's code
> under RTC and others under CTR.
> 
> -Bertrand
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

Re: RTC vs CTR (was: Concerning Sentry...)

[Brock Noland <br...@apache.org>]

On Tue, Nov 17, 2015 at 7:33 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> Not sure how to totally grok the below... It seems to
> imply, logically, that we cannot require either CTR or RTC.
> So what other method is there? Certainly we need both a
> Review and a Commit and one must be done before the other,
> right?

Sorry to be unclear, I was commenting on statements which appeared to
suggested, to me at least, RTC wasn't "the Apache way." Like you
suggested, I trust each community to make this decision on their own.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Jim Jagielski <ji...@jaguNET.com>]

> On Nov 20, 2015, at 9:02 AM, Ralph Goers <Ra...@dslextreme.com> wrote:
> 
> A combination approach seems like it would be the best to me. Is the process you guys use documented?  
> 
> As I said, the part that bothers me with the way RTC is done in the project I am involved in is that I can’t commit my own stuff.
> 

With many projects, the commit is actually a merge from a branch/tree
which was under CTR, so history is maintained.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Ralph Goers <ra...@dslextreme.com>]

A combination approach seems like it would be the best to me. Is the process you guys use documented?  

As I said, the part that bothers me with the way RTC is done in the project I am involved in is that I can’t commit my own stuff.

Ralph


> On Nov 20, 2015, at 6:09 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
> 
> Lets recall that 'review' is not just about trust (or whether
> or not it exists), it's also about this little thing called
> *oversight*. It's to ensure that at least 3 people are
> engaged enough to be able to not only vet the code/patch/whatever,
> but to make sure that should the original patch provider
> drop out of sight, that there are enough people around to
> keep that code up-to-date.
> 
> As Joe sez, this whole discussion seems weird to me. httpd
> (for example) uses RTC, CTR and Lazy Consensus simultaneously
> and works like a dream. And considering that httpd is pretty
> much the "standard" or "basis" for the Apache Way (or, at least
> one of the main ones), any suggestion that one of these methods
> is broken, or whatever, seems wonky.
> 
>> On Nov 17, 2015, at 9:05 AM, Ted Dunning <te...@gmail.com> wrote:
>> 
>> On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski <ji...@jagunet.com> wrote:
>> 
>>> Certainly we need both a
>>> Review and a Commit and one must be done before the other,
>>> right?
>>> 
>> 
>> Well, not necessarily.  We need a commit.  The review is, strictly
>> speaking, optional. That means that the three choices are C, RTC, CTR.  The
>> empty string is plausible, but implies a dead community.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Fri, Nov 20, 2015 at 11:47 AM, Ted Dunning <te...@gmail.com> wrote:
> On Sat, Nov 21, 2015 at 12:40 AM, Sam Ruby <ru...@intertwingly.net> wrote:
>
>> On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler
>> <Ro...@microsoft.com> wrote:
>> > Good point. I should add to my comments that even a CTR project uses RTC
>> for non-committers. And that a release vote means that at least three
>> people have reviewed the code from (at least) an IP standpoint, if not from
>> a code quality standpoint.
>> >
>> > In other words, +1
>> >
>> > However, RTC projects do not use a mix and that's the point of
>> contention here, some people feel it is suboptimal (I'm one, but others
>> disagree). The discussion is not whether CTR also uses RTC at points, I
>> believe that is a given.
>>
>> Let me be pedantic for a moment.  While RTC projects that use
>> Subversion may disallow work in branches, even by committers; such a
>> restriction isn't even possible in Git -- even for non committers.
>
> Not only isn't something you can forbid, it isn't even something that I
> could understand without reading your sentence three times.
>
> Git is all about branching. Forbidding branches is a non sequitur.

The most you can do in Git is to say that you can't do it in THIS
location or give it THAT name.  In which case, the inevitable response
will be, OK, I'll do it elsewhere and/or give it a different name.

- Sam Ruby

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Ted Dunning <te...@gmail.com>]

On Sat, Nov 21, 2015 at 12:40 AM, Sam Ruby <ru...@intertwingly.net> wrote:

> On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler
> <Ro...@microsoft.com> wrote:
> > Good point. I should add to my comments that even a CTR project uses RTC
> for non-committers. And that a release vote means that at least three
> people have reviewed the code from (at least) an IP standpoint, if not from
> a code quality standpoint.
> >
> > In other words, +1
> >
> > However, RTC projects do not use a mix and that's the point of
> contention here, some people feel it is suboptimal (I'm one, but others
> disagree). The discussion is not whether CTR also uses RTC at points, I
> believe that is a given.
>
> Let me be pedantic for a moment.  While RTC projects that use
> Subversion may disallow work in branches, even by committers; such a
> restriction isn't even possible in Git -- even for non committers.
>

Not only isn't something you can forbid, it isn't even something that I
could understand without reading your sentence three times.

Git is all about branching. Forbidding branches is a non sequitur.

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler
<Ro...@microsoft.com> wrote:
> Good point. I should add to my comments that even a CTR project uses RTC for non-committers. And that a release vote means that at least three people have reviewed the code from (at least) an IP standpoint, if not from a code quality standpoint.
>
> In other words, +1
>
> However, RTC projects do not use a mix and that's the point of contention here, some people feel it is suboptimal (I'm one, but others disagree). The discussion is not whether CTR also uses RTC at points, I believe that is a given.

Let me be pedantic for a moment.  While RTC projects that use
Subversion may disallow work in branches, even by committers; such a
restriction isn't even possible in Git -- even for non committers.

> Ross

- Sam Ruby

> -----Original Message-----
> From: sa3ruby@gmail.com [mailto:sa3ruby@gmail.com] On Behalf Of Sam Ruby
> Sent: Friday, November 20, 2015 7:43 AM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> +1 here too.
>
> Most projects here fall somewhere in a spectrum between "do whatever you want in a branch" and "don't release without having others approve your work".  Different projects put the point where CTR crosses over to RTC at different points.
>
> *shrug*
>
> - Sam Ruby
>
> P.S.  Personally a fan of CTR, but I'm starting to appreciate our infrastructure team's puppet workflow where everything (even one line
> changes) are done in a branch and everybody asks other person to merge the changes.
>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fINFRA%2fGit%2bworkflow%2bfor%2binfrastructure-puppet%2brepo&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d
>
> On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> ++1
>>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>>>
>>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>>> ...httpd for example) uses RTC, CTR and Lazy Consensus
>>>> simultaneously and works like a dream....
>>>
>>> Indeed - those are different tools that each have their own purpose.
>>> They just need to be applied in the right places and at the right
>>> time.
>>>
>>> -Bertrand
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Alex Harui <ah...@adobe.com>]

On 11/20/15, 8:23 AM, "Ross Gardler" <Ro...@microsoft.com> wrote:
>However, RTC projects do not use a mix and that's the point of contention
>here, some people feel it is suboptimal (I'm one, but others disagree).
>The discussion is not whether CTR also uses RTC at points, I believe that
>is a given.

That's the key for me.  A project can say it is:
1) CTR
2) RTC
3) Some combination.

Saying a project is CTR doesn't prevent someone from asking for a review
before committing something.
Saying a project is RTC does prevent someone from committing before
review, so unless there is further documentation about exceptions which
puts you in bucket 3, simply saying RTC prevents CTR, whereas the opposite
is not true.

-Alex

RE: RTC vs CTR (was: Concerning Sentry...)

[Ross Gardler <Ro...@microsoft.com>]

Good point. I should add to my comments that even a CTR project uses RTC for non-committers. And that a release vote means that at least three people have reviewed the code from (at least) an IP standpoint, if not from a code quality standpoint.

In other words, +1

However, RTC projects do not use a mix and that's the point of contention here, some people feel it is suboptimal (I'm one, but others disagree). The discussion is not whether CTR also uses RTC at points, I believe that is a given.

Ross

-----Original Message-----
From: sa3ruby@gmail.com [mailto:sa3ruby@gmail.com] On Behalf Of Sam Ruby
Sent: Friday, November 20, 2015 7:43 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)

+1 here too.

Most projects here fall somewhere in a spectrum between "do whatever you want in a branch" and "don't release without having others approve your work".  Different projects put the point where CTR crosses over to RTC at different points.

*shrug*

- Sam Ruby

P.S.  Personally a fan of CTR, but I'm starting to appreciate our infrastructure team's puppet workflow where everything (even one line
changes) are done in a branch and everybody asks other person to merge the changes.

https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fcwiki.apache.org%2fconfluence%2fdisplay%2fINFRA%2fGit%2bworkflow%2bfor%2binfrastructure-puppet%2brepo&data=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d

On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> ++1
>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>>
>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> ...httpd for example) uses RTC, CTR and Lazy Consensus 
>>> simultaneously and works like a dream....
>>
>> Indeed - those are different tools that each have their own purpose.
>> They just need to be applied in the right places and at the right 
>> time.
>>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Sam Ruby <ru...@intertwingly.net>]

+1 here too.

Most projects here fall somewhere in a spectrum between "do whatever
you want in a branch" and "don't release without having others approve
your work".  Different projects put the point where CTR crosses over
to RTC at different points.

*shrug*

- Sam Ruby

P.S.  Personally a fan of CTR, but I'm starting to appreciate our
infrastructure team's puppet workflow where everything (even one line
changes) are done in a branch and everybody asks other person to merge
the changes.

https://cwiki.apache.org/confluence/display/INFRA/Git+workflow+for+infrastructure-puppet+repo

On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> ++1
>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
>>
>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>>> ...httpd for example) uses RTC, CTR and Lazy Consensus
>>> simultaneously and works like a dream....
>>
>> Indeed - those are different tools that each have their own purpose.
>> They just need to be applied in the right places and at the right
>> time.
>>
>> -Bertrand
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Jim Jagielski <ji...@jaguNET.com>]

++1
> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bd...@apache.org> wrote:
> 
> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> ...httpd for example) uses RTC, CTR and Lazy Consensus
>> simultaneously and works like a dream....
> 
> Indeed - those are different tools that each have their own purpose.
> They just need to be applied in the right places and at the right
> time.
> 
> -Bertrand
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Bertrand Delacretaz <bd...@apache.org>]

On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> ...httpd for example) uses RTC, CTR and Lazy Consensus
> simultaneously and works like a dream....

Indeed - those are different tools that each have their own purpose.
They just need to be applied in the right places and at the right
time.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Jim Jagielski <ji...@jaguNET.com>]

Lets recall that 'review' is not just about trust (or whether
or not it exists), it's also about this little thing called
*oversight*. It's to ensure that at least 3 people are
engaged enough to be able to not only vet the code/patch/whatever,
but to make sure that should the original patch provider
drop out of sight, that there are enough people around to
keep that code up-to-date.

As Joe sez, this whole discussion seems weird to me. httpd
(for example) uses RTC, CTR and Lazy Consensus simultaneously
and works like a dream. And considering that httpd is pretty
much the "standard" or "basis" for the Apache Way (or, at least
one of the main ones), any suggestion that one of these methods
is broken, or whatever, seems wonky.

> On Nov 17, 2015, at 9:05 AM, Ted Dunning <te...@gmail.com> wrote:
> 
> On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski <ji...@jagunet.com> wrote:
> 
>> Certainly we need both a
>> Review and a Commit and one must be done before the other,
>> right?
>> 
> 
> Well, not necessarily.  We need a commit.  The review is, strictly
> speaking, optional. That means that the three choices are C, RTC, CTR.  The
> empty string is plausible, but implies a dead community.


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Ted Dunning <te...@gmail.com>]

On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski <ji...@jagunet.com> wrote:

> Certainly we need both a
> Review and a Commit and one must be done before the other,
> right?
>

Well, not necessarily.  We need a commit.  The review is, strictly
speaking, optional. That means that the three choices are C, RTC, CTR.  The
empty string is plausible, but implies a dead community.

Re: RTC vs CTR (was: Concerning Sentry...)

[Jim Jagielski <ji...@jaguNET.com>]

Not sure how to totally grok the below... It seems to
imply, logically, that we cannot require either CTR or RTC.
So what other method is there? Certainly we need both a
Review and a Commit and one must be done before the other,
right?

> On Nov 17, 2015, at 7:57 AM, Brock Noland <br...@apache.org> wrote:
> 
> On Tue, Nov 17, 2015 at 6:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> IMO, I trust our PMCs and PPMCs to know whether RTC or CTR, or some
>> combination of both, is better suited to their community and
>> their project. Both processes can work great, and both can be
>> perfect disasters.
> 
> 
> +1. I don't think it's been discussed but requiring CTR or RTC would
> IMO be imposing ones opinions on a community and I'd be strongly
> against such a requirement.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Brock Noland <br...@apache.org>]

On Tue, Nov 17, 2015 at 6:11 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> IMO, I trust our PMCs and PPMCs to know whether RTC or CTR, or some
> combination of both, is better suited to their community and
> their project. Both processes can work great, and both can be
> perfect disasters.


+1. I don't think it's been discussed but requiring CTR or RTC would
IMO be imposing ones opinions on a community and I'd be strongly
against such a requirement.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Jim Jagielski <ji...@jaguNET.com>]

IMO, I trust our PMCs and PPMCs to know whether RTC or CTR, or some
combination of both, is better suited to their community and
their project. Both processes can work great, and both can be
perfect disasters.

PS: Please don't extrapolate the above too far and somehow use
    it for biases and proposals where it doesn't apply :)

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Pierre Smits <pi...@gmail.com>]

I trust that mentors, like any other, project their biases first! Like we
see people do here. It is, no matter how much we dislike it, human nature.
How it pans out is subject to speculation.

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Tue, Nov 17, 2015 at 12:06 PM, Rob Vesse <rv...@dotnetrdf.org> wrote:

> On 17/11/2015 08:20, "Greg Stein" <gs...@gmail.com> wrote:
>
> >On Tue, Nov 17, 2015 at 1:53 AM, Bertrand Delacretaz
> ><bdelacretaz@apache.org
> >> wrote:
> >
> >> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Rob Vesse <rv...@dotnetrdf.org>]

On 17/11/2015 08:20, "Greg Stein" <gs...@gmail.com> wrote:

>On Tue, Nov 17, 2015 at 1:53 AM, Bertrand Delacretaz
><bdelacretaz@apache.org
>> wrote:
>
>> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Pierre Smits <pi...@gmail.com>]

I don't you mind having your opinion. I guess it is not based on measurable
facts. And if it were so, then someone else would come along and say: don't
trust the data!

Best regards.

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Tue, Nov 17, 2015 at 10:43 AM, Greg Stein <gs...@gmail.com> wrote:

> Of course it is community-based! (never said otherwise)
>
> And my points are attempting to inform people about the underlying
> principles of trust in these two modes of community operation. And (IMO)
> that RTC is a horrible underpinning, preventing an establishment of a true
> trust relationship among the members of the community. RTC leads with "I
> don't trust you". CTR leads with "I trust you."
>
> Others may justify their use of RTC under the rubric of "complexity", but
> as I stated else-thread that is merely an excuse. There is no
> justification, other than control. "Greg: you cannot fix javadoc tags. We
> don't trust you. Each fix must be reviewed first, and approved." Hah.
>
> -g
>
>
> On Tue, Nov 17, 2015 at 3:35 AM, Pierre Smits <pi...@gmail.com>
> wrote:
>
> > No... That is a resolution in play based on consensus by the community.
> You
> > may question that. But it is better done there.
> >
> > Best regards,
> >
> >
> >
> > Pierre Smits
> >
> > *OFBiz Extensions Marketplace*
> > http://oem.ofbizci.net/oci-2/
> >
> > On Tue, Nov 17, 2015 at 10:27 AM, Greg Stein <gs...@gmail.com> wrote:
> >
> > > Hunh? How do you get that? I trust my fellow committers. That's not
> > > projection.
> > >
> > > If I joined Hadoop right now, RTC says I cannot commit without review.
> > That
> > > is called "lack of trust". That I am unable to determine what is safe
> to
> > > commit, and what I feel I need help with to safely commit.
> > >
> > > -g
> > >
> > >
> > > On Tue, Nov 17, 2015 at 3:23 AM, Pierre Smits <pi...@gmail.com>
> > > wrote:
> > >
> > > > That is what I say: you're projecting.
> > > >
> > > > Best regards,
> > > >
> > > > Pierre Smits
> > > >
> > > > *OFBiz Extensions Marketplace*
> > > > http://oem.ofbizci.net/oci-2/
> > > >
> > > > On Tue, Nov 17, 2015 at 10:11 AM, Greg Stein <gs...@gmail.com>
> wrote:
> > > >
> > > > > On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <
> > pierre.smits@gmail.com>
> > > > > wrote:
> > > > > >...
> > > > >
> > > > > > And by the way, this has little to do with trust. More with hope.
> > As
> > > > in:
> > > > > we
> > > > > > hope they won't abuse our trust. It seems you're projecting trust
> > > > issues!
> > > > > >
> > > > >
> > > > > It is ALL about trust. I've worked in the httpd, apr, and svn
> > projects
> > > > > here. I trust all of my fellow community members to commit
> > > appropriately.
> > > > > Hope doesn't come into play at all. I trust them.
> > > > >
> > > > > -g
> > > > >
> > > >
> > >
> >
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

Of course it is community-based! (never said otherwise)

And my points are attempting to inform people about the underlying
principles of trust in these two modes of community operation. And (IMO)
that RTC is a horrible underpinning, preventing an establishment of a true
trust relationship among the members of the community. RTC leads with "I
don't trust you". CTR leads with "I trust you."

Others may justify their use of RTC under the rubric of "complexity", but
as I stated else-thread that is merely an excuse. There is no
justification, other than control. "Greg: you cannot fix javadoc tags. We
don't trust you. Each fix must be reviewed first, and approved." Hah.

-g


On Tue, Nov 17, 2015 at 3:35 AM, Pierre Smits <pi...@gmail.com>
wrote:

> No... That is a resolution in play based on consensus by the community. You
> may question that. But it is better done there.
>
> Best regards,
>
>
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Nov 17, 2015 at 10:27 AM, Greg Stein <gs...@gmail.com> wrote:
>
> > Hunh? How do you get that? I trust my fellow committers. That's not
> > projection.
> >
> > If I joined Hadoop right now, RTC says I cannot commit without review.
> That
> > is called "lack of trust". That I am unable to determine what is safe to
> > commit, and what I feel I need help with to safely commit.
> >
> > -g
> >
> >
> > On Tue, Nov 17, 2015 at 3:23 AM, Pierre Smits <pi...@gmail.com>
> > wrote:
> >
> > > That is what I say: you're projecting.
> > >
> > > Best regards,
> > >
> > > Pierre Smits
> > >
> > > *OFBiz Extensions Marketplace*
> > > http://oem.ofbizci.net/oci-2/
> > >
> > > On Tue, Nov 17, 2015 at 10:11 AM, Greg Stein <gs...@gmail.com> wrote:
> > >
> > > > On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <
> pierre.smits@gmail.com>
> > > > wrote:
> > > > >...
> > > >
> > > > > And by the way, this has little to do with trust. More with hope.
> As
> > > in:
> > > > we
> > > > > hope they won't abuse our trust. It seems you're projecting trust
> > > issues!
> > > > >
> > > >
> > > > It is ALL about trust. I've worked in the httpd, apr, and svn
> projects
> > > > here. I trust all of my fellow community members to commit
> > appropriately.
> > > > Hope doesn't come into play at all. I trust them.
> > > >
> > > > -g
> > > >
> > >
> >
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Pierre Smits <pi...@gmail.com>]

No... That is a resolution in play based on consensus by the community. You
may question that. But it is better done there.

Best regards,



Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Tue, Nov 17, 2015 at 10:27 AM, Greg Stein <gs...@gmail.com> wrote:

> Hunh? How do you get that? I trust my fellow committers. That's not
> projection.
>
> If I joined Hadoop right now, RTC says I cannot commit without review. That
> is called "lack of trust". That I am unable to determine what is safe to
> commit, and what I feel I need help with to safely commit.
>
> -g
>
>
> On Tue, Nov 17, 2015 at 3:23 AM, Pierre Smits <pi...@gmail.com>
> wrote:
>
> > That is what I say: you're projecting.
> >
> > Best regards,
> >
> > Pierre Smits
> >
> > *OFBiz Extensions Marketplace*
> > http://oem.ofbizci.net/oci-2/
> >
> > On Tue, Nov 17, 2015 at 10:11 AM, Greg Stein <gs...@gmail.com> wrote:
> >
> > > On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <pi...@gmail.com>
> > > wrote:
> > > >...
> > >
> > > > And by the way, this has little to do with trust. More with hope. As
> > in:
> > > we
> > > > hope they won't abuse our trust. It seems you're projecting trust
> > issues!
> > > >
> > >
> > > It is ALL about trust. I've worked in the httpd, apr, and svn projects
> > > here. I trust all of my fellow community members to commit
> appropriately.
> > > Hope doesn't come into play at all. I trust them.
> > >
> > > -g
> > >
> >
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

Hunh? How do you get that? I trust my fellow committers. That's not
projection.

If I joined Hadoop right now, RTC says I cannot commit without review. That
is called "lack of trust". That I am unable to determine what is safe to
commit, and what I feel I need help with to safely commit.

-g


On Tue, Nov 17, 2015 at 3:23 AM, Pierre Smits <pi...@gmail.com>
wrote:

> That is what I say: you're projecting.
>
> Best regards,
>
> Pierre Smits
>
> *OFBiz Extensions Marketplace*
> http://oem.ofbizci.net/oci-2/
>
> On Tue, Nov 17, 2015 at 10:11 AM, Greg Stein <gs...@gmail.com> wrote:
>
> > On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <pi...@gmail.com>
> > wrote:
> > >...
> >
> > > And by the way, this has little to do with trust. More with hope. As
> in:
> > we
> > > hope they won't abuse our trust. It seems you're projecting trust
> issues!
> > >
> >
> > It is ALL about trust. I've worked in the httpd, apr, and svn projects
> > here. I trust all of my fellow community members to commit appropriately.
> > Hope doesn't come into play at all. I trust them.
> >
> > -g
> >
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Pierre Smits <pi...@gmail.com>]

That is what I say: you're projecting.

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Tue, Nov 17, 2015 at 10:11 AM, Greg Stein <gs...@gmail.com> wrote:

> On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <pi...@gmail.com>
> wrote:
> >...
>
> > And by the way, this has little to do with trust. More with hope. As in:
> we
> > hope they won't abuse our trust. It seems you're projecting trust issues!
> >
>
> It is ALL about trust. I've worked in the httpd, apr, and svn projects
> here. I trust all of my fellow community members to commit appropriately.
> Hope doesn't come into play at all. I trust them.
>
> -g
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 17, 2015 at 3:02 AM, Pierre Smits <pi...@gmail.com>
wrote:
>...

> And by the way, this has little to do with trust. More with hope. As in: we
> hope they won't abuse our trust. It seems you're projecting trust issues!
>

It is ALL about trust. I've worked in the httpd, apr, and svn projects
here. I trust all of my fellow community members to commit appropriately.
Hope doesn't come into play at all. I trust them.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Pierre Smits <pi...@gmail.com>]

This is not just about having your own way. This is working with the rest
of the community. If you feel that CTR is wrong, make a case in the
community, build consensus and adhere accordingly. If you feel that RTC is
wrong, make a case in the community, build consensus and work accordingly.

There are no rights and wrongs here.

And by the way, this has little to do with trust. More with hope. As in: we
hope they won't abuse our trust. It seems you're projecting trust issues!

Best regards,

Pierre Smits

*OFBiz Extensions Marketplace*
http://oem.ofbizci.net/oci-2/

On Tue, Nov 17, 2015 at 9:20 AM, Greg Stein <gs...@gmail.com> wrote:

> On Tue, Nov 17, 2015 at 1:53 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Tue, Nov 17, 2015 at 1:53 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:

> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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

Re: RTC vs CTR (was: Concerning Sentry...)

[Bertrand Delacretaz <bd...@apache.org>]

On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning <te...@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".

Like all sharp tools I think RTC has its place, but shouldn't be
abused. It's perfectly possible to have some parts of a project's code
under RTC and others under CTR.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Ted Dunning <te...@gmail.com>]

On Tue, Nov 17, 2015 at 7:56 AM, Todd Lipcon <to...@cloudera.com> wrote:

> > I have always found the "complex project" to merely be an excuse for
> > control/no-trust.
> >
> > All software is hard. Your project is no more complex than others.
> >
> >
> Having worked on projects in pretty much every layer of the software stack,
> I think we'll just have to agree to disagree.


Hm....

I really have to agree with Todd here.  Systems with formal verification
requirements or strong real-time requirements are much harder to modify
correctly than certain other kinds of code that I have worked on.  Systems
with lower level languages can make these much harder again.

Differing levels of reliability requirements also change the level of
difficulty.  I worked once on a hard real-time medical instrument and am
proud to say that our methods of extensive review resulted in zero bugs
ever detected in the core instrument over tens of thousands of units
shipped and used over >10 years even though we only had stone-age tools for
development.  That was *hard* to do.  Most of the code that I work on is
*much* easier. We succeeded then due to our embrace of aggressive and
ongoing review.

RTC can be framed as "I don't trust you to do things right". It might even
be objectively true for some codes.  I have had far more success in framing
RTC as "I trust you to help me make things better".  The former statement
leads to systems like Greg describes.  The latter statement can bring
people together like Todd describes.

I do believe that CTR is appropriate in many settings, but I do think that
in the extreme that leads to something like github or CPAN or CRAN or PyPi
or npm. There is very little community connection between different
projects (on github) or modules (on CRAN or PyPi), but there is also a nice
freedom to innovate (and freedom to fail). Just as you need to take
measures to avoid RTC being used as a club, you need to take measures to
avoid the community drifting apart with CTR due to low interaction levels.

Metaphorically, with strong binding you have gravitational collapse of a
community which can lead to lots of heat and possibly a supernova or black
hole. With weak binding, you can have the universe expand into a cold quiet
place.  Neither extreme is particularly desirable.

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@cloudera.com>]

On Mon, Nov 16, 2015 at 2:50 PM, Greg Stein <gs...@gmail.com> wrote:

> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <to...@apache.org> wrote:
> >...
>
> > 1) You're right, I don't trust anybody to make code changes to a complex
> > project with zero oversight. I currently work on a project that I
> >
>
> I have always found the "complex project" to merely be an excuse for
> control/no-trust.
>
> All software is hard. Your project is no more complex than others.
>
>
Having worked on projects in pretty much every layer of the software stack,
I think we'll just have to agree to disagree.

Thankfully, the actual rules of the ASF have nothing to say on this matter,
and it's diversity of opinions that makes it an interesting community. I
just don't want projects in incubation (or considering incubation) to think
that the ASF mandates one or the other style of development.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: RTC vs CTR (was: Concerning Sentry...)

[Todd Lipcon <to...@cloudera.com>]

On Tue, Nov 17, 2015 at 8:50 AM, Steve Loughran <st...@hortonworks.com>
wrote:
... snipped...

>
> But at the same time, RTC dissuades me from doing the minor stuff, because
> the effort to submit a patch to correct a spelling error in a comment is so
> high. I think it can endanger code quality.
>
> There's also the fact that even those bigger patches I may do, will need
> to be reviewed before commit —and there's a backlog on the Hadoop codebase
> which includes a lot of mine. Other people are as lax about reviewing those
> patches as I (sadly) am about reviewing patches from people other than me.
> It takes effort and time, and if you are working on something full time,
> where that means evening and weekends as well as daytime, then its easy to
> neglect things.
>

Big +1. This is one of the reasons that I'm a big fan of gerrit for
contributions, and why a lot of people are big fans of github pull requests.

With the "post patch on JIRA (or mailing list)" workflow, the committer, in
order to review, has to download the patch, apply it, look at a diff with
more context, rebuild the project, type up notes, and paste them back into
the JIRA. If it's a simple patch and there are no notes, the committer
still has to manually apply it, write a commit message, and push from their
own box -- typically at least running a build in between to make sure they
didn't somehow mess up the patch application or commit their own WIP junk
from their repository.

This makes it at least a 5-10 minute process (often longer if my local
repository is in bad shape) to commit a trivial change contributed by a new
contributor.

Compare to gerrit: I see a patch up for review. It shows me the diff in
context along with the author's commit message. For a trivial patch, I can
review it in 30 seconds. When it's good to go, I hit a "Submit" button and
the rest of the workflow is taken care of. End-to-end time less than a
minute.

It might seem petty, but I've witnessed my own behavior in these two
different workflows. On Hadoop, I rarely go through the patch queue,
because I know that it's going to be a big pain to review even trivial
changes. There's a vicious cycle, because when changes aren't reviewed
quickly, they fall out of date, and then become harder to review, take more
effort from contributors to rebase, etc. On other projects that use gerrit,
I rarely see a mergeable trivial patch last longer than a couple hours
before someone clicks the necessary buttons to merge it.

This may all seem orthogonal to RTC vs CTR, but I think my point is this:
the actual review workflow strongly affects the rate of progress in RTC
projects.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

Re: RTC vs CTR (was: Concerning Sentry...)

[Joe Schaefer <jo...@gmail.com>]

Come on folks it's not cut and dry.  Httpd uses both without fuss about
roles, trust, etc.  This is a process issue much like the choice of version
control tool you select, it really is not a big deal.

On Wednesday, November 18, 2015, Dave Fisher <da...@comcast.net> wrote:

> I see the essence of what it means to be a committer. Being trusted to
> both do the correct action and be willing to listen objectively to
> criticism. In an CTR project it is clear to me that the point where a
> project grants Committership should be the point where the PMC wants to
> treat an individual's contribution as CTR rather than RTC. How does an RTC
> project make THAT important decision?
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Nov 17, 2015, at 3:53 PM, Upayavira <uv@odoko.co.uk <javascript:;>>
> wrote:
> >
> >
> >
> >> On Tue, Nov 17, 2015, at 06:01 PM, Rob Vesse wrote:
> >>> On 17/11/2015 16:50, "Steve Loughran" <stevel@hortonworks.com
> <javascript:;>> wrote:
> >>>
> >>> If someone were to have some metrics of projects, the state of
> >>> patches/pull requests would be a key issue.
> >>
> >> https://github.com/rvesse/gh-pr-stats
> >>
> >> Given a GitHub project generates statistics about the state of the Pull
> >> Requests in the project e.g.
> >>
> >> ./pr-stats apache hadoop
> >>
> >> Fairly basic tool but should give you enough to gauge where things are
> >
> > One of the things that this conversation seems to miss, to me, is
> > defining what "C" is.
> >
> > In some sense, C is simply the act of publishing a change. The change
> > MUST be published before the review, otherwise review is, obviously,
> > impossible (how can you review something you cannot see?)
> >
> > What's important, as I think Greg was saying earlier, is *how we relate
> > to each other*. Do I need to ask for PERMISSION to finally push a change
> > through, or do my colleagues trust me to do the right thing, knowing
> > that I'll listen to their feedback, whether the review mechanism is a
> > commit mailing list, a JIRA ticket or a pull request.
> >
> > Please define what you mean by CTR or RTC before diving into further
> > discussions about their relative merit. Otherwise we'll get locked into
> > yet another ongoing discussion that leads nowhere!
> >
> > Upayavira
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> > For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

In RTC, a contributor sending in a patch, a pull request, or a JIRA/patch
is handled exactly the same as any other committer. None are trusted to
apply their change, until they receive review and permission from others.
So you would think that "everybody" would get committer status on Day One.
Why not? No effective difference between contributor and committer. "Oh, he
gets a committer privilege bit to apply the change." ... That's it. A
committer bit. No other difference from John Doe contributor.

"Hey! We want to invite you to become a committer!" ... "oh. gee. yay. I'm
so enthused. what a difference. NOT."

On Wed, Nov 18, 2015 at 12:06 AM, Dave Fisher <da...@comcast.net> wrote:

> I see the essence of what it means to be a committer. Being trusted to
> both do the correct action and be willing to listen objectively to
> criticism. In an CTR project it is clear to me that the point where a
> project grants Committership should be the point where the PMC wants to
> treat an individual's contribution as CTR rather than RTC. How does an RTC
> project make THAT important decision?
>
> Regards,
> Dave
>

Re: RTC vs CTR (was: Concerning Sentry...)

[Dave Fisher <da...@comcast.net>]

I see the essence of what it means to be a committer. Being trusted to both do the correct action and be willing to listen objectively to criticism. In an CTR project it is clear to me that the point where a project grants Committership should be the point where the PMC wants to treat an individual's contribution as CTR rather than RTC. How does an RTC project make THAT important decision?

Regards,
Dave

Sent from my iPhone

> On Nov 17, 2015, at 3:53 PM, Upayavira <uv...@odoko.co.uk> wrote:
> 
> 
> 
>> On Tue, Nov 17, 2015, at 06:01 PM, Rob Vesse wrote:
>>> On 17/11/2015 16:50, "Steve Loughran" <st...@hortonworks.com> wrote:
>>> 
>>> If someone were to have some metrics of projects, the state of
>>> patches/pull requests would be a key issue.
>> 
>> https://github.com/rvesse/gh-pr-stats
>> 
>> Given a GitHub project generates statistics about the state of the Pull
>> Requests in the project e.g.
>> 
>> ./pr-stats apache hadoop
>> 
>> Fairly basic tool but should give you enough to gauge where things are
> 
> One of the things that this conversation seems to miss, to me, is
> defining what "C" is.
> 
> In some sense, C is simply the act of publishing a change. The change
> MUST be published before the review, otherwise review is, obviously,
> impossible (how can you review something you cannot see?)
> 
> What's important, as I think Greg was saying earlier, is *how we relate
> to each other*. Do I need to ask for PERMISSION to finally push a change
> through, or do my colleagues trust me to do the right thing, knowing
> that I'll listen to their feedback, whether the review mechanism is a
> commit mailing list, a JIRA ticket or a pull request.
> 
> Please define what you mean by CTR or RTC before diving into further
> discussions about their relative merit. Otherwise we'll get locked into
> yet another ongoing discussion that leads nowhere!
> 
> Upayavira
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Upayavira <uv...@odoko.co.uk>]

On Tue, Nov 17, 2015, at 06:01 PM, Rob Vesse wrote:
> On 17/11/2015 16:50, "Steve Loughran" <st...@hortonworks.com> wrote:
> 
> >If someone were to have some metrics of projects, the state of
> >patches/pull requests would be a key issue.
> 
> https://github.com/rvesse/gh-pr-stats
> 
> Given a GitHub project generates statistics about the state of the Pull
> Requests in the project e.g.
> 
> ./pr-stats apache hadoop
> 
> Fairly basic tool but should give you enough to gauge where things are

One of the things that this conversation seems to miss, to me, is
defining what "C" is.

In some sense, C is simply the act of publishing a change. The change
MUST be published before the review, otherwise review is, obviously,
impossible (how can you review something you cannot see?)

What's important, as I think Greg was saying earlier, is *how we relate
to each other*. Do I need to ask for PERMISSION to finally push a change
through, or do my colleagues trust me to do the right thing, knowing
that I'll listen to their feedback, whether the review mechanism is a
commit mailing list, a JIRA ticket or a pull request.

Please define what you mean by CTR or RTC before diving into further
discussions about their relative merit. Otherwise we'll get locked into
yet another ongoing discussion that leads nowhere!

Upayavira

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Rob Vesse <rv...@dotnetrdf.org>]

On 17/11/2015 16:50, "Steve Loughran" <st...@hortonworks.com> wrote:

>If someone were to have some metrics of projects, the state of
>patches/pull requests would be a key issue.

https://github.com/rvesse/gh-pr-stats

Given a GitHub project generates statistics about the state of the Pull
Requests in the project e.g.

./pr-stats apache hadoop

Fairly basic tool but should give you enough to gauge where things are

Rob





---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Steve Loughran <st...@hortonworks.com>]

> On 16 Nov 2015, at 22:50, Greg Stein <gs...@gmail.com> wrote:
> 
> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <to...@apache.org> wrote:
>> ...
> 
>> 1) You're right, I don't trust anybody to make code changes to a complex
>> project with zero oversight. I currently work on a project that I
>> 
> 
> I have always found the "complex project" to merely be an excuse for
> control/no-trust.
> 
> All software is hard. Your project is no more complex than others.
> 
> -g


FWIW some of the projects I'm is CTR; for stuff where it's less complex/critical then yes I enjoy the freedom. I can not only push stuff out fast, I can keep that code hygiene up by doing side things: comments, spelling corrections, other tuning, as I go along.

But I do have to track what's going on by others and look at their changes -though now via SCM history within the IDE, rather than .patch files and pull requests.

Where I find myself agreeing with todd, however is the bits of the system where getting it wrong could lead to fundamental losses of petabytes worth of data. Which is what you can do if you get something wrong with HDFS or HBase: hence RTC is justifiable. Indeed, get something wrong with the consensus protocols of zookeeper would potentially cause problems for : Hadoop, HBase, cassandra, Mesos, Accumulo & many other things —which is why I'm happy for people other than myself to understand the maths behind it  ["Zab: High-performance broadcast for primary-backup systems" | https://web.stanford.edu/class/cs347/reading/zab.pdf ]

But at the same time, RTC dissuades me from doing the minor stuff, because the effort to submit a patch to correct a spelling error in a comment is so high. I think it can endanger code quality.

There's also the fact that even those bigger patches I may do, will need to be reviewed before commit —and there's a backlog on the Hadoop codebase which includes a lot of mine. Other people are as lax about reviewing those patches as I (sadly) am about reviewing patches from people other than me. It takes effort and time, and if you are working on something full time, where that means evening and weekends as well as daytime, then its easy to neglect things.

If someone were to have some metrics of projects, the state of patches/pull requests would be a key issue.



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Stephen Connolly <st...@gmail.com>]

On Wednesday 25 November 2015, Steve Loughran <st...@hortonworks.com>
wrote:

>
> > On 22 Nov 2015, at 22:34, Branko Čibej <brane@apache.org <javascript:;>>
> wrote:
> >
> >
> > The major question here, for me, is: if the project is RTC, then why
> > would I make an effort to become a committer if at the end of the day
> > I'm still not trusted to know when to ask for review? It'd be less work
> > to throw patches at the developers and let them deal with the pain of
> > reviewing and applying.
> >
>
> what you gain as committer is not so much the right to do the housekeeping
> of svn commit/git commit, it's the right to commit other people's code in
> after reviewing it.
>
> And while anyone is encouraged to review patches on JIRA/github, etc, your
> ability to +1 code says you are trusted to make changes to the code without
> breaking things. That is: your knowledge of the code is deemed sufficient
> to be able to review the work of others, to help guide them into a state
> where it can be committed, and if not: explain why not. You just still have
> to go through the same process of submission and review with your peers, so
> there is a guarantee that 1 other person is always aware of what you do.
>
> That ability to +1 code is the right and the responsibility.


I believe that to be an anti-pattern.

At the Maven project, we started to track on votes which votes were from
the PMC (ie binding for making a release with the legal protection of the
foundation)

The nett effect was a reduction of engagement from the community... When
they saw these "+1 (binding)" votes being treated differently, they stopped
voting on releases...

So now we are trying to rebuild the engagement... Much harder after you
have lost it than not to lose it in the first place.

Now releases are more visible than commits, but I believe the same
principle applies.

With CTR anyone can be a "drive by" reviewer. With RTC the "drive by"
reviewer doesn't have the same status... So it is harder to engage them and
pull them into the community


>
>
>
> > How would it feel to get a mail like this:
> >
> >    Congratulations! The developers of Project FOO invite you to become
> >    a committer. All your patches to date have been perfect and your
> >    other contributions outstanding. Of course we still won't let you
> >    commit your changes unless [brass hats] have reviewed and approved
> >    them; we operate by a review-then-commit process. The only real
> >    benefit of committer status is that you can now review other
> >    people's patches and have a binding opinion, unless [brass hats]
> >    have written otherwise in the bylaws.
>
> yes: you get to have a direct say in what goes into the codebase.
>
> you also get a duty: you need to review other people's work. We need to
> encourage more of that in the Hadoop codebase. I know its a chore, but
> Yetus is helping, as should the github integration.
>
> >
> >    P.S.: Any competent engineer will immediately see that the optimal
> >    way to proceed is to join an informal group of committers that
> >    mutually +1 each other's patches without unnecessary hassle, and/or
> >    ingratiate yourself with [brass hats] to achieve equivalent results.
> >    After all, it's all about building a healthy community, right?
>
> it would, though it'd stand out. And if you want things to work without
> fielding support calls, you want the quality of what goes in to be high -no
> matter from whom it came.
>
> If you work in specific part of the code, you do end up knowing the people
> who also work there, their skills, their weaknesses: who is most likely to
> break things. So you may show some favouritism to people  you trust.
> Explicit tradings of patches? Not me.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>


-- 
Sent from my phone

Re: RTC vs CTR (was: Concerning Sentry...)

[Stephen Connolly <st...@gmail.com>]

On Wednesday 25 November 2015, Steve Loughran <st...@hortonworks.com>
wrote:

>
> > On 22 Nov 2015, at 22:34, Branko Čibej <brane@apache.org <javascript:;>>
> wrote:
> >
> >
> > The major question here, for me, is: if the project is RTC, then why
> > would I make an effort to become a committer if at the end of the day
> > I'm still not trusted to know when to ask for review? It'd be less work
> > to throw patches at the developers and let them deal with the pain of
> > reviewing and applying.
> >
>
> what you gain as committer is not so much the right to do the housekeeping
> of svn commit/git commit, it's the right to commit other people's code in
> after reviewing it.
>
> And while anyone is encouraged to review patches on JIRA/github, etc, your
> ability to +1 code says you are trusted to make changes to the code without
> breaking things. That is: your knowledge of the code is deemed sufficient
> to be able to review the work of others, to help guide them into a state
> where it can be committed, and if not: explain why not. You just still have
> to go through the same process of submission and review with your peers, so
> there is a guarantee that 1 other person is always aware of what you do.
>
> That ability to +1 code is the right and the responsibility.


I believe that to be an anti-pattern.

At the Maven project, we started to track on votes which votes were from
the PMC (ie binding for making a release with the legal protection of the
foundation)

The nett effect was a reduction of engagement from the community... When
they saw these "+1 (binding)" votes being treated differently, they stopped
voting on releases...

So now we are trying to rebuild the engagement... Much harder after you
have lost it than not to lose it in the first place.

Now releases are more visible than commits, but I believe the same
principle applies.

With CTR anyone can be a "drive by" reviewer. With RTC the "drive by"
reviewer doesn't have the same status... So it is harder to engage them and
pull them into the community


>
>
>
> > How would it feel to get a mail like this:
> >
> >    Congratulations! The developers of Project FOO invite you to become
> >    a committer. All your patches to date have been perfect and your
> >    other contributions outstanding. Of course we still won't let you
> >    commit your changes unless [brass hats] have reviewed and approved
> >    them; we operate by a review-then-commit process. The only real
> >    benefit of committer status is that you can now review other
> >    people's patches and have a binding opinion, unless [brass hats]
> >    have written otherwise in the bylaws.
>
> yes: you get to have a direct say in what goes into the codebase.
>
> you also get a duty: you need to review other people's work. We need to
> encourage more of that in the Hadoop codebase. I know its a chore, but
> Yetus is helping, as should the github integration.
>
> >
> >    P.S.: Any competent engineer will immediately see that the optimal
> >    way to proceed is to join an informal group of committers that
> >    mutually +1 each other's patches without unnecessary hassle, and/or
> >    ingratiate yourself with [brass hats] to achieve equivalent results.
> >    After all, it's all about building a healthy community, right?
>
> it would, though it'd stand out. And if you want things to work without
> fielding support calls, you want the quality of what goes in to be high -no
> matter from whom it came.
>
> If you work in specific part of the code, you do end up knowing the people
> who also work there, their skills, their weaknesses: who is most likely to
> break things. So you may show some favouritism to people  you trust.
> Explicit tradings of patches? Not me.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> <javascript:;>
> For additional commands, e-mail: general-help@incubator.apache.org
> <javascript:;>
>


-- 
Sent from my phone

Re: RTC vs CTR (was: Concerning Sentry...)

[Steve Loughran <st...@hortonworks.com>]

> On 22 Nov 2015, at 22:34, Branko Čibej <br...@apache.org> wrote:
> 
> 
> The major question here, for me, is: if the project is RTC, then why
> would I make an effort to become a committer if at the end of the day
> I'm still not trusted to know when to ask for review? It'd be less work
> to throw patches at the developers and let them deal with the pain of
> reviewing and applying.
> 

what you gain as committer is not so much the right to do the housekeeping of svn commit/git commit, it's the right to commit other people's code in after reviewing it.

And while anyone is encouraged to review patches on JIRA/github, etc, your ability to +1 code says you are trusted to make changes to the code without breaking things. That is: your knowledge of the code is deemed sufficient to be able to review the work of others, to help guide them into a state where it can be committed, and if not: explain why not. You just still have to go through the same process of submission and review with your peers, so there is a guarantee that 1 other person is always aware of what you do.

That ability to +1 code is the right and the responsibility. 



> How would it feel to get a mail like this:
> 
>    Congratulations! The developers of Project FOO invite you to become
>    a committer. All your patches to date have been perfect and your
>    other contributions outstanding. Of course we still won't let you
>    commit your changes unless [brass hats] have reviewed and approved
>    them; we operate by a review-then-commit process. The only real
>    benefit of committer status is that you can now review other
>    people's patches and have a binding opinion, unless [brass hats]
>    have written otherwise in the bylaws.

yes: you get to have a direct say in what goes into the codebase.

you also get a duty: you need to review other people's work. We need to encourage more of that in the Hadoop codebase. I know its a chore, but Yetus is helping, as should the github integration.

> 
>    P.S.: Any competent engineer will immediately see that the optimal
>    way to proceed is to join an informal group of committers that
>    mutually +1 each other's patches without unnecessary hassle, and/or
>    ingratiate yourself with [brass hats] to achieve equivalent results.
>    After all, it's all about building a healthy community, right?

it would, though it'd stand out. And if you want things to work without fielding support calls, you want the quality of what goes in to be high -no matter from whom it came.

If you work in specific part of the code, you do end up knowing the people who also work there, their skills, their weaknesses: who is most likely to break things. So you may show some favouritism to people  you trust. Explicit tradings of patches? Not me.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Branko Čibej <br...@apache.org>]

On 18.11.2015 01:35, Konstantin Boudnik wrote:
> On Mon, Nov 16, 2015 at 04:50PM, Greg Stein wrote:
>> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <to...@apache.org> wrote:
>>> ...
>>> 1) You're right, I don't trust anybody to make code changes to a complex
>>> project with zero oversight. I currently work on a project that I
>>>
>> I have always found the "complex project" to merely be an excuse for
>> control/no-trust.
>>
>> All software is hard. Your project is no more complex than others.
> +1 on that and what Ralph said. CTR provides a huge stimuli not to
> write-n-push a crappy or semi-baked code. Precisely because of the trust put
> on them by the community of the peers.

The major question here, for me, is: if the project is RTC, then why
would I make an effort to become a committer if at the end of the day
I'm still not trusted to know when to ask for review? It'd be less work
to throw patches at the developers and let them deal with the pain of
reviewing and applying.

How would it feel to get a mail like this:

    Congratulations! The developers of Project FOO invite you to become
    a committer. All your patches to date have been perfect and your
    other contributions outstanding. Of course we still won't let you
    commit your changes unless [brass hats] have reviewed and approved
    them; we operate by a review-then-commit process. The only real
    benefit of committer status is that you can now review other
    people's patches and have a binding opinion, unless [brass hats]
    have written otherwise in the bylaws.

    P.S.: Any competent engineer will immediately see that the optimal
    way to proceed is to join an informal group of committers that
    mutually +1 each other's patches without unnecessary hassle, and/or
    ingratiate yourself with [brass hats] to achieve equivalent results.
    After all, it's all about building a healthy community, right?


Betcha there are RTC projects out there that find this satire hauntingly
familiar.


-- Brane


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: RTC vs CTR (was: Concerning Sentry...)

[Konstantin Boudnik <co...@apache.org>]

On Mon, Nov 16, 2015 at 04:50PM, Greg Stein wrote:
> On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <to...@apache.org> wrote:
> >...
> 
> > 1) You're right, I don't trust anybody to make code changes to a complex
> > project with zero oversight. I currently work on a project that I
> >
> 
> I have always found the "complex project" to merely be an excuse for
> control/no-trust.
> 
> All software is hard. Your project is no more complex than others.

+1 on that and what Ralph said. CTR provides a huge stimuli not to
write-n-push a crappy or semi-baked code. Precisely because of the trust put
on them by the community of the peers.

Cos

Re: RTC vs CTR (was: Concerning Sentry...)

[Greg Stein <gs...@gmail.com>]

On Mon, Nov 16, 2015 at 11:53 AM, Todd Lipcon <to...@apache.org> wrote:
>...

> 1) You're right, I don't trust anybody to make code changes to a complex
> project with zero oversight. I currently work on a project that I
>

I have always found the "complex project" to merely be an excuse for
control/no-trust.

All software is hard. Your project is no more complex than others.

-g

Re: RTC vs CTR (was: Concerning Sentry...)

[Andrew Purtell <an...@gmail.com>]

> After writing the above, I started to feel it was familiar and remember a very similar discussion on hbase-dev last year:
http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_Dz+_rZumfWVyA0tkvXTk4saEie6PWpgs2mxvSbQ8HOpQ@mail.gmail.com%3E - I'd recommend people go check that one out to see the various viewpoints.

That was a great discussion covering all manner of ideas, crazy or otherwise. Key is we brought the discussion out to a public forum and had a no drama floating of views and options with an aim to build consensus. 

That consensus on HBase was that RTC is preferred over the alternative, pretty much for the code quality reasons Todd discusses below. Any other project could come to a different consensus. I don't think we need to or should prescribe RTC or CTR up front. Each community should have this discussion and come to a rational consensus of what choice they should make for their particular needs. 


> On Nov 16, 2015, at 9:53 AM, Todd Lipcon <to...@apache.org> wrote:
> 
> [editing subject since the discussion has veered away from Sentry]
> 
> On Mon, Nov 16, 2015 at 7:56 AM, Ralph Goers <ra...@dslextreme.com>
> wrote:
> 
>> And I have to disagree with you Joe. To me, a mandatory RTC policy says
>> “we don’t trust anybody”. Sure, it doesn’t discriminate, but it is also a
>> PITA. One project I mentored uses RTC along with ReviewBoard and mandates
>> that you cannot commit your own work and every commit must be formally
>> reviewed. I have found this process to be so onerous that I have never
>> committed any code to the project, even though I really would like to.  I
>> find the pace of this project to be fairly slow.  But it seems to fit
>> within the corporate culture that most of the committers seem to work in.
>> 
>> OTOH, I am involved in a project that uses CTR but where feature branches
>> are frequently created to allow others to review and improve significant
>> new work before it is integrated. As a consequence, new features are
>> introduced at a much faster pace in this project.
> 
> I've seen this RTC vs CTR discussion come up a number of times over the
> last ~6 years that I've been involved in ASF projects. For every strong
> opinion in favor of CTR (like yours) there is a strong opinion in favor of
> RTC (like mine).
> 
> The quick summary of my viewpoint is:
> 
> 1) You're right, I don't trust anybody to make code changes to a complex
> project with zero oversight. I currently work on a project that I
> originally started, and was the only engineer on for a few months. Even
> when I make changes to code that I wrote 100% of the module, I get others
> to review my work, and you know what? It turns out better for it. Sometimes
> they find bugs. Often they find areas where I didn't comment the code well,
> design it as well as I could have, or missed potential performance
> optimizations.
> 
> Coding's hard. Coding on complex projects is even harder. Some projects
> aren't complex, and maybe on those a CTR policy makes a lot more sense. But
> distributed systems, database storage engines, etc, are pretty hard to get
> right, even for the "experts". I'm always glad to have a second pair of
> eyes before I introduce a bug that takes down critical infrastructure.
> 
> 2) Regardless of trust, code review helps build _shared ownership_ of code.
> In community projects, without code review, it's easy to end up with "pet
> features" or areas of code that only one person understands. When that
> person moves on to new employment or new interests, the project is stuck
> with a bunch of source code that no one understands how to maintain.
> Forcing the original author to get some reviews before committing ensures
> that there is a more likely path to project continuity after they move on
> to new pastures.
> 
> 3) Code reviews are a great way for engineers to learn from others in the
> community. Earlier in my career, I certainly learned a lot from the
> committers on projects like Hadoop and HBase where I "cut my teeth". And
> even as a long-time committer on these systems, I still learn new things
> from reviewing code written by newer members of the community. Review is
> where a lot of the cross-contributor interaction takes place, so it helps
> build a cohesive community.
> 
> Given #2 and #3, I see RTC as an extension of "community over code". Sure,
> it might slow down the introduction of a new feature or fix to have to wait
> to get a review from another community member. But, that's just code.
> Getting more eyes and hands on the code builds the community.
> 
> After writing the above, I started to feel it was familiar and remember a
> very similar discussion on hbase-dev last year:
> http://mail-archives.apache.org/mod_mbox/hbase-dev/201508.mbox/%3CCA+RK=_Dz+_rZumfWVyA0tkvXTk4saEie6PWpgs2mxvSbQ8HOpQ@mail.gmail.com%3E
> - I'd recommend people go check that one out to see the various viewpoints.
> 
> I don't anticipate that the above arguments will convince you, or anyone
> else who believes in CTR, to change your mind. But, as mentioned in some
> other recent incubator threads, let's not use the incubator as a
> battleground for personal opinions. There are successful Apache projects
> following all sorts of development models, and the important thing is only
> that (a) projects build inclusive communities, and (b) projects follow
> proper licensing/release/etc processes for legal reasons.
> 
> -Todd