subject:"RTC vs CTR \(was\: Concerning Sentry...\)"

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  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  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

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

On Wed, Nov 25, 2015 at 5:18 PM, Greg Stein  wrote:
> On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby  wrote:
>
>> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-25 Thread Konstantin Boudnik

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  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 
> > wrote:
> >
> >> I have to completely disagree and find your assertion vaguely offensive.
> >>
> >> > On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
> >> >
> >> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
> >> > 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"

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

2015-11-25 Thread Ralph Goers

> On Nov 25, 2015, at 3:22 PM, Todd Lipcon  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-25 Thread Todd Lipcon

On Wed, Nov 25, 2015 at 7:06 PM, Ralph Goers 
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...)

2015-11-25 Thread Chris Douglas

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  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 
> wrote:
>
>> I have to completely disagree and find your assertion vaguely offensive.
>>
>> > On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
>> >
>> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
>> > 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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

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

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

On Wed, Nov 25, 2015 at 9:13 PM, Konstantin Boudnik  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-25 Thread Andrew Purtell

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 
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  wrote:
> >
> > On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> >> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <
> elecha...@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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@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...)

2015-11-25 Thread Steve Loughran

> On 22 Nov 2015, at 22:34, Branko Čibej  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik  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  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...)

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

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

2015-11-25 Thread Ralph Goers

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  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  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  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  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  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  wrote:
>> 
>>> Not replying to this mail specifically, but to the thread in

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

2015-11-25 Thread Andrew Purtell

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  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 
> wrote:
> 
>> I have to completely disagree and find your assertion vaguely offensive.
>> 
>>> On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
>>> 
>>> On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
>>> 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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 

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

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

On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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


On Nov 25, 2015, at 11:32 PM, Ralph Goers  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  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  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

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

On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby  wrote:

> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein  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...)

2015-11-25 Thread Todd Lipcon

On Wed, Nov 25, 2015 at 1:32 PM, Ralph Goers 
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...)

2015-11-25 Thread Andrew Purtell

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

> On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
> 
> On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
> 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

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  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  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  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  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 
> >> 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-unsubscr...@incubator.apache.org
>  For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
>
>

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

2015-11-25 Thread Jim Jagielski

> On Nov 25, 2015, at 3:49 PM, Greg Stein  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
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...)

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  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  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

On Nov 25, 2015, at 10:37 PM, Greg Stein  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...)

On Wed, Nov 25, 2015 at 3:39 PM, Greg Stein 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

On Wed, Nov 25, 2015 at 3:27 PM, Sam Ruby  wrote:

> On Wed, Nov 25, 2015 at 3:39 PM, Greg Stein  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...)

2015-11-25 Thread Upayavira

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  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  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-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >

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

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

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 
wrote:

> I have to completely disagree and find your assertion vaguely offensive.
>
> > On Nov 25, 2015, at 12:32 PM, Greg Stein  wrote:
> >
> > On Wed, Nov 25, 2015 at 12:44 PM, Andrew Purtell 
> > 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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

2015-11-25 Thread Pierre Smits

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  wrote:

> On Wed, Nov 25, 2015 at 5:18 PM, Greg Stein  wrote:
> > On Wed, Nov 25, 2015 at 4:02 PM, Sam Ruby 
> wrote:
> >
> >> On Wed, Nov 25, 2015 at 4:51 PM, Greg Stein  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

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

2015-11-24 Thread Konstantin Boudnik

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


signature.asc
Description: Digital signature

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

2015-11-24 Thread Konstantin Boudnik

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.pember...@gmail.com] 
> Sent: Monday, November 23, 2015 5:49 PM
> To: general-incubator <general@incubator.apache.org>
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> 
> On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein <gst...@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 <gst...@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
> >


signature.asc
Description: Digital signature

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

2015-11-24 Thread Brock Noland

> On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-24 Thread Ross Gardler

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:br...@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 <gst...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-24 Thread Greg Stein

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 <ross.gard...@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:br...@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 <gst...@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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

2015-11-24 Thread Brock Noland

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 <gst...@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 <ross.gard...@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:br...@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 <gst...@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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

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

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

On Sun, Nov 22, 2015 at 11:37 PM, Todd Lipcon  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...)

On Mon, Nov 23, 2015 at 4:29 AM, Harbs  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...)

On Mon, Nov 23, 2015 at 12:33 AM, Reynold Xin  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...)

On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby  wrote:

> On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein  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...)

2015-11-23 Thread Sam Ruby

On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-23 Thread Dennis E. Hamilton



> -Original Message-
> From: r...@databricks.com [mailto:r...@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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-23 Thread Harbs

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

2015-11-23 Thread Sam Ruby

On Mon, Nov 23, 2015 at 7:10 AM, Greg Stein  wrote:
> On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-23 Thread Jim Jagielski


> On Nov 22, 2015, at 7:57 AM, Greg Stein  wrote:
> 
> On Sun, Nov 22, 2015 at 5:42 AM, Harbs  wrote:
>> ...
> 
>> If there is a disagreement, it seems to be part semantics, part version
>> control technologies (i.e. SVN optimized workflow vs Git optimized
>> workflow) and part an actual difference in how to handle certain
>> situations. It seems to me that the actual disagreement is pretty small. ;-)
>> 
> 
> No, it isn't small. I believe RTC as a standard policy is actively harmful.
> Proponents use excuses for it, but using RTC for trunk/master is (IMO)
> always a mechanism for control, exclusion, and a lack of trust of your
> peers/community.
> 

Well, I don't agree that it is harmful, but maybe it's
a holdover from the early, early, early days of httpd when
Brian wouldn't commit anything unless there were 3 +1 on
the proposed patch... That seemed to have worked OK :)


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

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

2015-11-23 Thread Niall Pemberton

On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein  wrote:

> On Mon, Nov 23, 2015 at 5:57 AM, Sam Ruby  wrote:
>
> > On Mon, Nov 23, 2015 at 5:20 AM, Greg Stein  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...)

2015-11-23 Thread Ross Gardler

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

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

On Mon, Nov 23, 2015 at 12:10 PM, Greg Stein <gst...@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 <gst...@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...)

2015-11-22 Thread Todd Lipcon

On Sun, Nov 22, 2015 at 12:18 PM, Konstantin Boudnik  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=user%3Aapache=Repositories=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...)

2015-11-22 Thread Reynold Xin

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  wrote:

> On Sun, Nov 22, 2015 at 12:18 PM, Konstantin Boudnik 
> 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=user%3Aapache=Repositories=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...)

2015-11-22 Thread Henry Saputra

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 
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  > wrote:
> >
> > On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> >> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <
> elecha...@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-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

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

2015-11-22 Thread Branko Čibej

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  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-22 Thread Harbs

So. After this long debate, it seems like no one is on either extreme of the 
CTR/RTC spectrum. The entire debate seems to be exactly where within the 
spectrum one likes to be.

It seems reasonable that the exact position varies from project to project or 
even within different pieces within a project…

If there is a disagreement, it seems to be part semantics, part version control 
technologies (i.e. SVN optimized workflow vs Git optimized workflow) and part 
an actual difference in how to handle certain situations. It seems to me that 
the actual disagreement is pretty small. ;-)

Harbs

On Nov 20, 2015, at 8:50 PM, Todd Lipcon  wrote:

> On Thu, Nov 19, 2015 at 6:49 PM, Greg Stein  wrote:
> 
>> Todd: as Ross notes, your three points about code reviews in a CTR project
>> are quite valid, and match accepted engineering practices.
>> 
>> 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"[1] to make
>> even the simplest of changes under RTC. Even worse, from else-thread, it
>> sounds like under your control scheme, you don't even allow the committer
>> to apply their own change [after review].
> 
> 
> They can apply their own change once someone else has +1ed it. On Hadoop,
> for example, the usual workflow when I review another committer's patch is
> that I give them a +1 and they commit it themselves. On gerrit or github,
> because the actual "commit" process is just clicking a button on a web UI,
> it's more normal for the reviewer to be the one to commit it after giving
> the +1 review, but both happen and either one's fine.
> 
> 
>> A committer can give a binding +1
>> to somebody else's work. But they aren't trusted to give that to their own
>> work. Just like a drive-by contributor can't be trusted.
>> 
> 
> Right, they can't give it to their own work because it defeats the purpose
> of the code review (discussed earlier).
> 
> Of course it's not hard and fast -- eg fixing a broken build due to a
> missing 'import' statement or something would be totally fine to commit
> without review, or fixing a grammar mistake in a comment, or anything else
> that's obviously trivial. But once actual code is changing, it's expected
> to get two pairs of eyes.
> 
> -Todd


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

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

2015-11-22 Thread Greg Stein

On Sun, Nov 22, 2015 at 5:42 AM, Harbs  wrote:
>...

> If there is a disagreement, it seems to be part semantics, part version
> control technologies (i.e. SVN optimized workflow vs Git optimized
> workflow) and part an actual difference in how to handle certain
> situations. It seems to me that the actual disagreement is pretty small. ;-)
>

No, it isn't small. I believe RTC as a standard policy is actively harmful.
Proponents use excuses for it, but using RTC for trunk/master is (IMO)
always a mechanism for control, exclusion, and a lack of trust of your
peers/community.

Cheers,
-g

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

2015-11-22 Thread Mary the sonnetor

I'm am in the process of learning all this fascinating tech things. That's
why I was looking at the different outputs.  I'm so not hurting or meddling
in anybody's life nor I ever want to. Just like the opposing people
received a chance. I too deserve 1. I'm sorry someone feels that way about
me but I have a lot of enriching knowledge to give with a warm heart and
great care for people.

inspirational laison

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

2015-11-22 Thread Konstantin Boudnik

On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny 
> 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.



signature.asc
Description: Digital signature

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

2015-11-22 Thread Konstantin Boudnik

On Tue, Nov 17, 2015 at 06:06PM, Todd Lipcon wrote:
> On Tue, Nov 17, 2015 at 5:57 PM, Konstantin Boudnik  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


signature.asc
Description: Digital signature

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

2015-11-22 Thread Joe Schaefer

Thank you Mary and welcome aboard!  You are an inspiration
for others!

On Sun, Nov 22, 2015 at 8:08 AM, Mary the sonnetor <
marywantsalittlelamb...@gmail.com> wrote:

> I'm am in the process of learning all this fascinating tech things. That's
> why I was looking at the different outputs.  I'm so not hurting or meddling
> in anybody's life nor I ever want to. Just like the opposing people
> received a chance. I too deserve 1. I'm sorry someone feels that way about
> me but I have a lot of enriching knowledge to give with a warm heart and
> great care for people.
>
> inspirational laison
>

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

2015-11-22 Thread Ralph Goers

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  wrote:
> 
> On Tue, Nov 17, 2015 at 11:12PM, Todd Lipcon wrote:
>> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny 
>> 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-21 Thread Niclas Hedhman

I have now, days later, Reviewed this Thread and Commit to a veto of the
whole debate, Can't agree That it is Rewarding for anyone... ;-)

On Sat, Nov 21, 2015 at 2:50 AM, Todd Lipcon  wrote:

> On Thu, Nov 19, 2015 at 6:49 PM, Greg Stein  wrote:
>
> > Todd: as Ross notes, your three points about code reviews in a CTR
> project
> > are quite valid, and match accepted engineering practices.
> >
> > 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"[1] to make
> > even the simplest of changes under RTC. Even worse, from else-thread, it
> > sounds like under your control scheme, you don't even allow the committer
> > to apply their own change [after review].
>
>
> They can apply their own change once someone else has +1ed it. On Hadoop,
> for example, the usual workflow when I review another committer's patch is
> that I give them a +1 and they commit it themselves. On gerrit or github,
> because the actual "commit" process is just clicking a button on a web UI,
> it's more normal for the reviewer to be the one to commit it after giving
> the +1 review, but both happen and either one's fine.
>
>
> > A committer can give a binding +1
> > to somebody else's work. But they aren't trusted to give that to their
> own
> > work. Just like a drive-by contributor can't be trusted.
> >
>
> Right, they can't give it to their own work because it defeats the purpose
> of the code review (discussed earlier).
>
> Of course it's not hard and fast -- eg fixing a broken build due to a
> missing 'import' statement or something would be totally fine to commit
> without review, or fixing a grammar mistake in a comment, or anything else
> that's obviously trivial. But once actual code is changing, it's expected
> to get two pairs of eyes.
>
> -Todd
>



-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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

2015-11-21 Thread Greg Stein

On Sat, Nov 21, 2015 at 10:10 PM, Niclas Hedhman  wrote:

> I have now, days later, Reviewed this Thread and Commit to a veto of the
>

RTC


> whole debate, Can't agree That it is Rewarding for anyone... ;-)
>

CTR

... I saw what you did there :-)

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

2015-11-20 Thread Jim Jagielski


> On Nov 20, 2015, at 9:02 AM, Ralph Goers  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-20 Thread Ralph Goers

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  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  wrote:
>> 
>> On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
> 



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

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

2015-11-20 Thread Bertrand Delacretaz

On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-20 Thread Jim Jagielski

++1
> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz  
> wrote:
> 
> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski  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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

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

2015-11-20 Thread Jim Jagielski

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  wrote:
> 
> On Tue, Nov 17, 2015 at 10:33 PM, Jim Jagielski  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-20 Thread Ross Gardler

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: sa3r...@gmail.com [mailto:sa3r...@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=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d

On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <j...@jagunet.com> wrote:
> ++1
>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bdelacre...@apache.org> 
>> wrote:
>>
>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <j...@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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

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

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

2015-11-20 Thread Ted Dunning

On Sat, Nov 21, 2015 at 12:40 AM, Sam Ruby  wrote:

> On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler
>  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...)

2015-11-20 Thread Sam Ruby

+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  wrote:
> ++1
>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz  
>> wrote:
>>
>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski  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-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

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

2015-11-20 Thread Sam Ruby

On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler
<ross.gard...@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: sa3r...@gmail.com [mailto:sa3r...@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=01%7c01%7cRoss.Gardler%40microsoft.com%7c44adea1c26a1499d757f08d2f1c13a31%7c72f988bf86f141af91ab2d7cd011db47%7c1=485qCjFlNzNCg1JvNgDxSpSe79EwynxdP9RcmoEOsxw%3d
>
> On Fri, Nov 20, 2015 at 9:54 AM, Jim Jagielski <j...@jagunet.com> wrote:
>> ++1
>>> On Nov 20, 2015, at 9:38 AM, Bertrand Delacretaz <bdelacre...@apache.org> 
>>> wrote:
>>>
>>> On Fri, Nov 20, 2015 at 8:09 AM, Jim Jagielski <j...@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-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org

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

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

2015-11-20 Thread Alex Harui

On 11/20/15, 8:23 AM, "Ross Gardler"  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...)

2015-11-20 Thread Sam Ruby

On Fri, Nov 20, 2015 at 11:47 AM, Ted Dunning  wrote:
> On Sat, Nov 21, 2015 at 12:40 AM, Sam Ruby  wrote:
>
>> On Fri, Nov 20, 2015 at 11:23 AM, Ross Gardler
>>  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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

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

2015-11-20 Thread Todd Lipcon

On Thu, Nov 19, 2015 at 6:49 PM, Greg Stein  wrote:

> Todd: as Ross notes, your three points about code reviews in a CTR project
> are quite valid, and match accepted engineering practices.
>
> 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"[1] to make
> even the simplest of changes under RTC. Even worse, from else-thread, it
> sounds like under your control scheme, you don't even allow the committer
> to apply their own change [after review].

They can apply their own change once someone else has +1ed it. On Hadoop,
for example, the usual workflow when I review another committer's patch is
that I give them a +1 and they commit it themselves. On gerrit or github,
because the actual "commit" process is just clicking a button on a web UI,
it's more normal for the reviewer to be the one to commit it after giving
the +1 review, but both happen and either one's fine.

> A committer can give a binding +1
> to somebody else's work. But they aren't trusted to give that to their own
> work. Just like a drive-by contributor can't be trusted.
>

Right, they can't give it to their own work because it defeats the purpose
of the code review (discussed earlier).

Of course it's not hard and fast -- eg fixing a broken build due to a
missing 'import' statement or something would be totally fine to commit
without review, or fixing a grammar mistake in a comment, or anything else
that's obviously trivial. But once actual code is changing, it's expected
to get two pairs of eyes.

-Todd

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

2015-11-19 Thread Chris Nauroth

Some projects use the git Signed-off-by field in the commit log to
differentiate the author from the reviewer.

--Chris Nauroth




On 11/19/15, 10:58 AM, "Ralph Goers"  wrote:

>And there is another problem I have. Maybe it isn¹t true of all projects,
>but the one I am involved with says the author can¹t commit his own code.
>So the commit logs will not reflect who actually authored the code but
>who reviewed it. 
>
>I could probably tolerate RTC if I had to have the commit somewhere it
>could be reviewed, I had to wait for the review and fix any defects and
>then could commit the code myself (ideally even if no one actually
>reviewed it). That process isn¹t really much different than what I do for
>my larger commits anyway. But just submitting something for review and
>then hoping someone reviews it and then hoping someone commits it takes
>all the joy out of it for me.
>
>Ralph
>
>> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
>> 
>> 
>> Sure, that's a big problem with some RTC workflows. Using gerrit or
>>github
>> PRs makes the flow much easier -- for a trivial or small patch, the sort
>> that a "drive-by" contributor typically contributes, there probably
>>won't
>> be any review comments. So, they just push the patch for review, and
>>they
>> can be out of the loop for the rest of it. If the patch requires small
>> revisions (eg addressing a typo or something) I think it's fine for the
>> reviewer to just make the change themselves and commit on behalf of the
>> original author to avoid the issue you've raised. Most RTC workflows
>>permit
>> this kind of thing in my experience.
>
>
>
>-
>To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>For additional commands, e-mail: general-h...@incubator.apache.org
>
>


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

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

And there is another problem I have. Maybe it isn’t true of all projects, but 
the one I am involved with says the author can’t commit his own code. So the 
commit logs will not reflect who actually authored the code but who reviewed 
it. 

I could probably tolerate RTC if I had to have the commit somewhere it could be 
reviewed, I had to wait for the review and fix any defects and then could 
commit the code myself (ideally even if no one actually reviewed it). That 
process isn’t really much different than what I do for my larger commits 
anyway. But just submitting something for review and then hoping someone 
reviews it and then hoping someone commits it takes all the joy out of it for 
me.

Ralph

> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> 
> 
> Sure, that's a big problem with some RTC workflows. Using gerrit or github
> PRs makes the flow much easier -- for a trivial or small patch, the sort
> that a "drive-by" contributor typically contributes, there probably won't
> be any review comments. So, they just push the patch for review, and they
> can be out of the loop for the rest of it. If the patch requires small
> revisions (eg addressing a typo or something) I think it's fine for the
> reviewer to just make the change themselves and commit on behalf of the
> original author to avoid the issue you've raised. Most RTC workflows permit
> this kind of thing in my experience.

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

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

Trick question, as I'd never work under that model :-)

Apache Subversion is CTR, with a very low bar to get commit access to
portions of the tree or a branch (only PMC members get access to whole
tree, so we grant full access and PMC membership simultaneously). We don't
need a fancy label for "contributor who is a committer" because such a
concept is anathema to the Subversion community's peer respect model.

On Thu, Nov 19, 2015 at 6:38 PM, Ralph Goers 
wrote:

> Greg, which of these do you use when the “contributor” is a committer?
> Remember the model here is that the author is never allowed to commit their
> own code.
>
> Ralph
>
> > On Nov 19, 2015, at 3:10 PM, Greg Stein  wrote:
> >
> > The Apache Subversion project does something similar:
> >
> >
> http://subversion.apache.org/docs/community-guide/conventions.html#crediting
> >
> > We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
> > On Nov 19, 2015 1:57 PM, "Chris Nauroth" 
> wrote:
> >
> >> Some projects use the git Signed-off-by field in the commit log to
> >> differentiate the author from the reviewer.
> >>
> >> --Chris Nauroth
> >>
> >>
> >>
> >>
> >> On 11/19/15, 10:58 AM, "Ralph Goers" 
> wrote:
> >>
> >>> And there is another problem I have. Maybe it isn¹t true of all
> projects,
> >>> but the one I am involved with says the author can¹t commit his own
> code.
> >>> So the commit logs will not reflect who actually authored the code but
> >>> who reviewed it.
> >>>
> >>> I could probably tolerate RTC if I had to have the commit somewhere it
> >>> could be reviewed, I had to wait for the review and fix any defects and
> >>> then could commit the code myself (ideally even if no one actually
> >>> reviewed it). That process isn¹t really much different than what I do
> for
> >>> my larger commits anyway. But just submitting something for review and
> >>> then hoping someone reviews it and then hoping someone commits it takes
> >>> all the joy out of it for me.
> >>>
> >>> Ralph
> >>>
>  On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> 
> 
>  Sure, that's a big problem with some RTC workflows. Using gerrit or
>  github
>  PRs makes the flow much easier -- for a trivial or small patch, the
> sort
>  that a "drive-by" contributor typically contributes, there probably
>  won't
>  be any review comments. So, they just push the patch for review, and
>  they
>  can be out of the loop for the rest of it. If the patch requires small
>  revisions (eg addressing a typo or something) I think it's fine for
> the
>  reviewer to just make the change themselves and commit on behalf of
> the
>  original author to avoid the issue you've raised. Most RTC workflows
>  permit
>  this kind of thing in my experience.
> >>>
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >>>
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

Greg, which of these do you use when the “contributor” is a committer? Remember 
the model here is that the author is never allowed to commit their own code.

Ralph

> On Nov 19, 2015, at 3:10 PM, Greg Stein  wrote:
> 
> The Apache Subversion project does something similar:
> 
> http://subversion.apache.org/docs/community-guide/conventions.html#crediting
> 
> We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
> On Nov 19, 2015 1:57 PM, "Chris Nauroth"  wrote:
> 
>> Some projects use the git Signed-off-by field in the commit log to
>> differentiate the author from the reviewer.
>> 
>> --Chris Nauroth
>> 
>> 
>> 
>> 
>> On 11/19/15, 10:58 AM, "Ralph Goers"  wrote:
>> 
>>> And there is another problem I have. Maybe it isn¹t true of all projects,
>>> but the one I am involved with says the author can¹t commit his own code.
>>> So the commit logs will not reflect who actually authored the code but
>>> who reviewed it.
>>> 
>>> I could probably tolerate RTC if I had to have the commit somewhere it
>>> could be reviewed, I had to wait for the review and fix any defects and
>>> then could commit the code myself (ideally even if no one actually
>>> reviewed it). That process isn¹t really much different than what I do for
>>> my larger commits anyway. But just submitting something for review and
>>> then hoping someone reviews it and then hoping someone commits it takes
>>> all the joy out of it for me.
>>> 
>>> Ralph
>>> 
 On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
 
 
 Sure, that's a big problem with some RTC workflows. Using gerrit or
 github
 PRs makes the flow much easier -- for a trivial or small patch, the sort
 that a "drive-by" contributor typically contributes, there probably
 won't
 be any review comments. So, they just push the patch for review, and
 they
 can be out of the loop for the rest of it. If the patch requires small
 revisions (eg addressing a typo or something) I think it's fine for the
 reviewer to just make the change themselves and commit on behalf of the
 original author to avoid the issue you've raised. Most RTC workflows
 permit
 this kind of thing in my experience.
>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 



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

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

The Apache Subversion project does something similar:

http://subversion.apache.org/docs/community-guide/conventions.html#crediting

We have a tool ("contribulyzer") that analyzes them. It's pretty neat.
On Nov 19, 2015 1:57 PM, "Chris Nauroth"  wrote:

> Some projects use the git Signed-off-by field in the commit log to
> differentiate the author from the reviewer.
>
> --Chris Nauroth
>
>
>
>
> On 11/19/15, 10:58 AM, "Ralph Goers"  wrote:
>
> >And there is another problem I have. Maybe it isn¹t true of all projects,
> >but the one I am involved with says the author can¹t commit his own code.
> >So the commit logs will not reflect who actually authored the code but
> >who reviewed it.
> >
> >I could probably tolerate RTC if I had to have the commit somewhere it
> >could be reviewed, I had to wait for the review and fix any defects and
> >then could commit the code myself (ideally even if no one actually
> >reviewed it). That process isn¹t really much different than what I do for
> >my larger commits anyway. But just submitting something for review and
> >then hoping someone reviews it and then hoping someone commits it takes
> >all the joy out of it for me.
> >
> >Ralph
> >
> >> On Nov 19, 2015, at 10:10 AM, Todd Lipcon  wrote:
> >>
> >>
> >> Sure, that's a big problem with some RTC workflows. Using gerrit or
> >>github
> >> PRs makes the flow much easier -- for a trivial or small patch, the sort
> >> that a "drive-by" contributor typically contributes, there probably
> >>won't
> >> be any review comments. So, they just push the patch for review, and
> >>they
> >> can be out of the loop for the rest of it. If the patch requires small
> >> revisions (eg addressing a typo or something) I think it's fine for the
> >> reviewer to just make the change themselves and commit on behalf of the
> >> original author to avoid the issue you've raised. Most RTC workflows
> >>permit
> >> this kind of thing in my experience.
> >
> >
> >
> >-
> >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

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

On Thu, Nov 19, 2015 at 8:10 PM, Ralph Goers 
wrote:
>...

> of people wanting to join. I am sure this is going to be a controversial
> statement, but I have noticed that the projects that I’ve seen do this
> often have a fair number of committers who are paid to work on the project
> by their employer and I have to admit that I have wondered if these
> projects do this actually want to limit participation.
>

Yeup. And this kind of monkey business is why the Board specifically
requires PMCs to document their additions. A static PMC membership may be a
sign of exclusion. This kind of behavior is why the Board has completely
emptied two PMCs in the Foundation's history, and made them regrow
themselves organically.

As I said at the start of this thread: RTC is a mechanism for control, not
for managing "complex projects".

Cheers,
-g

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

Yes, it was a trick question. But it proves my point. I can’t imagine a world 
where someone would refuse to participate in a project because it was CTR, but 
in my view this variation of RTC definitely limits the number of people wanting 
to join. I am sure this is going to be a controversial statement, but I have 
noticed that the projects that I’ve seen do this often have a fair number of 
committers who are paid to work on the project by their employer and I have to 
admit that I have wondered if these projects do this actually want to limit 
participation.

Ralph

> On Nov 19, 2015, at 6:05 PM, Greg Stein  wrote:
> 
> Trick question, as I'd never work under that model :-)
> 
> Apache Subversion is CTR, with a very low bar to get commit access to
> portions of the tree or a branch (only PMC members get access to whole
> tree, so we grant full access and PMC membership simultaneously). We don't
> need a fancy label for "contributor who is a committer" because such a
> concept is anathema to the Subversion community's peer respect model.
> 
> On Thu, Nov 19, 2015 at 6:38 PM, Ralph Goers 
> wrote:
> 
>> Greg, which of these do you use when the “contributor” is a committer?
>> Remember the model here is that the author is never allowed to commit their
>> own code.

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

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

Todd: as Ross notes, your three points about code reviews in a CTR project
are quite valid, and match accepted engineering practices.

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"[1] to make
even the simplest of changes under RTC. Even worse, from else-thread, it
sounds like under your control scheme, you don't even allow the committer
to apply their own change [after review]. A committer can give a binding +1
to somebody else's work. But they aren't trusted to give that to their own
work. Just like a drive-by contributor can't be trusted.

-g

[1] thanks to Upayavira for capturing the essence of RTC: it is a
"permission" mechanism for control.

On Wed, Nov 18, 2015 at 3:16 AM, Ross Gardler <ross.gard...@microsoft.com>
wrote:

> Interesting, Todd, can you identify which of your three arguments for CTR
> are not present in RTC.
>
> Ross
>
> -Original Message-
> From: Todd Lipcon [mailto:t...@cloudera.com]
> Sent: Tuesday, November 17, 2015 11:23 PM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein <gst...@gmail.com> wrote:
>
> > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon <t...@apache.org> wrote:
> > >...
> >
> > > I think it's a _plus_ that contributors and committers contribute
> > > code in the same way -- it's more of a level playing field for new
> > > people contributing to the project.
> > >
> >
> > "level playing field"?? seriously??
> >
> > I find no logical or valid reasoning to drag committers down to the
> > same level as drive-by contributors.
> >
>
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
>
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
>
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
>
> -Todd
>

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

None of your statements below are any different between RTC or CTR. The only 
time it makes aa difference is if no one does reviews.  My feeling is that a 
community that insists on RTC believes that code will not be reviewed unless 
committers are forced to do it.

All I can say, is that for me personally I have found the process of having to 
create a patch, submit a code review, wait for the review and participate in 
it, then wait for the commit to be onerous enough that I just don’t bother.  As 
I said, in a CTR community there are many times where branches are created and 
the code is reviewed there before being merged because the authors believe the 
code is significant enough to require it.  The author is then the one who 
merges the branch once the reviews are complete.  To be perfectly honest, this 
pretty much exactly matches the way software is created in the development team 
I work with in the $day$ job too.

Ralph

> On Nov 18, 2015, at 12:22 AM, Todd Lipcon  wrote:
> 
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
> 
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
> 
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
> 
> -Todd

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

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

2015-11-19 Thread Todd Lipcon

On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers 
wrote:

> None of your statements below are any different between RTC or CTR. The
> only time it makes aa difference is if no one does reviews.  My feeling is
> that a community that insists on RTC believes that code will not be
> reviewed unless committers are forced to do it.
>

Yep, that's my assumption. It's much more fun to write code than review it,
so "forcing" people to do it is a good idea. The other worry is that, in a
large community of developers, an implicit "people probably read the
commits as they come in" doesn't scale. Should every person read every
commit? Probably not. How do you know if someone else has already read the
commit, or signed up to do so? What if it takes you a few days to get
around to reviewing something, and by that point there are already a bunch
more patches stacked up on top making it impossible to revert or difficult
to modify? Who's in charge of fixing the bugs or issues in a post-commit
review?

I'm sure it works fine for many communities (I use CTR on some internal
infrastructure within small teams where bugs are less costly and the rate
of development is slow). But it doesn't work for all.

>
> All I can say, is that for me personally I have found the process of
> having to create a patch, submit a code review, wait for the review and
> participate in it, then wait for the commit to be onerous enough that I
> just don’t bother.

Sure, that's a big problem with some RTC workflows. Using gerrit or github
PRs makes the flow much easier -- for a trivial or small patch, the sort
that a "drive-by" contributor typically contributes, there probably won't
be any review comments. So, they just push the patch for review, and they
can be out of the loop for the rest of it. If the patch requires small
revisions (eg addressing a typo or something) I think it's fine for the
reviewer to just make the change themselves and commit on behalf of the
original author to avoid the issue you've raised. Most RTC workflows permit
this kind of thing in my experience.

> As I said, in a CTR community there are many times where branches are
> created and the code is reviewed there before being merged because the
> authors believe the code is significant enough to require it.

Amusingly enough, the RTC communities I'm a part of do the opposite: you
can make a branch which operates under CTR, so long as it's reviewed
sufficiently prior to its merge into trunk. This is great for rapid
development and prototyping when a small number of contributors are working
together on a new project.

-Todd
-- 
Todd Lipcon
Software Engineer, Cloudera

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