On Thu, Nov 26, 2015 at 10:56 AM, Harbs wrote:
>...
> So technically, the review is after the commit (to a central staging
> repo), but it’s mandatory before the commit is officially accepted and will
> be checked out from the (central approved) repo. It’s an interesting
> approach.
>
> (I realiz
FWIW:
I just now looked at Gerrit (being it’s what sparked this discussion) and I
think that it falls in that category between classic CTR and RTC. I was reading
this document which gives an overview.[1] The review there happens IN the
central repo, but it’s mandatory before content is checked
This saga jumped the shark right about the time Mary the sonnetor weighted
in.
On Thursday, November 26, 2015, Ralph Goers
wrote:
> Sorry Jim. As an attempt to shut down a thread, this wasn't a very good
> one. Not a single poster in this thread has a problem with the word, or
> the concept of,
Sorry Jim. As an attempt to shut down a thread, this wasn't a very good one.
Not a single poster in this thread has a problem with the word, or the concept
of, "review". It is the process that is the issue and what the impact of that
process is upon a community.
Ralph
> On Nov 26, 2015, at 6:
OK, ok... we are at diminishing returns here with people
no longer, imo, listening to what others are saying...
We have, as a foundation, and HAVE HAD RTC and CTR for years
and decades. There are times when one or the other are Good
and when they are Bad. Those exact times will, generally,
vary de
I concur. Chris' email is very insightful, and very well written. It is
great food for thought, for each workflow approach.
Thanks, Chris.
... food.. thx... Happy Thanksgiving!
-g
On Nov 26, 2015 4:28 AM, "Steve Loughran" wrote:
>
> This is really good essay on the whole topic. I don't think I'
This is really good essay on the whole topic. I don't think I've seen a post on
any asf list which uses both "existential threat" and "desiderata". I also like
the implication that RTC is a function of the complexity of the team, rather
than just the code. Every project I've worked on —open or
On Wednesday 25 November 2015, Steve Loughran
wrote:
>
> > 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
On Wednesday 25 November 2015, Steve Loughran
wrote:
>
> > 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
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
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
> 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 com
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-u
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 attem
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, bu
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.
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 caug
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
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?
N
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
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 c
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 disagr
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 i
> 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 pro
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
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
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
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 per
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 you
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/
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
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 ba
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:
>
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, an
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 cons
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
> tha
> 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
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 t
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
Spoilsport ;-)
On 25 November 2015 at 16:47, 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
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"
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
re
-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 A
'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...)
&g
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: Concern
> 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
Monday, November 23, 2015 5:49 PM
> To: general-incubator
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> 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
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 _offici
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
Subject: Re: RTC vs CTR (was: Concerning Sentry...)
O
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
> > > po
> 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 differenc
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 p
> -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]
> Commit
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
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
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 fo
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 co
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
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 th
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
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 v
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
> tha
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 pr
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,
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
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
> > p
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
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 bu
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 th
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 pro
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 :-)
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 c
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
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
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 mean
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 (a
...@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
il.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 with
+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
++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 purpo
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.
> 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 stuf
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 provide
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 empl
our 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...)
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 stat
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 "con
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.a
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 fie
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 autho
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
From: Todd Lipcon [mailto:t...@cloudera.com]
Sent: Thursday, November 19, 2015 9:11 AM
To: general@incubator.apache.org
Subject: Re: RTC vs CTR (was: Concerning Sentry...)
On Thu, Nov 19, 2015 at 8:16 AM, Ralph Goers
wrote:
> None of your statements below are any different between RTC or CTR
Sorry for extending the thread, but now I'm curious...
On 11/19/15, 9:10 AM, "Todd Lipcon" wrote:
>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 a
On Thu, Nov 19, 2015 at 11:10 AM, Todd Lipcon wrote:
> 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 in
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 commit
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 pe
On Wed, Nov 18, 2015 at 4:31 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> I believe the issue here is that with CTR it is very easy to miss the 72h
> lazy consensus voting (with an assumed +1 absence any votes cast) that most
> CTR projects operate under... and thus it can also
Le 18/11/15 17:54, Ross Gardler a écrit :
> Summarizing:
>
> In a healthy project I believe that the only significant things that change
> between CTR and RTC are:
>
> 1) speed of commit (CTR is faster)
> 2) quality of master, not releases (RTC catches most issues before commit,
> CTR shortly aft
To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On 18 November 2015 at 14:24, Emmanuel Lécharny
> wrote:
>
> > Le 18/11/15 14:34, Stephen Connolly a écrit :
> > > On Wednesday 18
1 - 100 of 154 matches
Mail list logo
