You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Matthieu Riou <ma...@offthelip.org> on 2009/11/11 17:09:39 UTC
Review-Then-Commit
Hi guys,
What's the take of other mentors and the IPMC on podlings practicing RTC?
I'm asking because some seem to see it as a blocker for graduation whereas I
see it much more as a development methodology with little community impact
and therefore no real influence on graduation. Strong opinions here?
Thanks,
Matthieu
Re: Review-Then-Commit
Posted by Bruce Snyder <br...@gmail.com>.
On Wed, Nov 11, 2009 at 9:21 AM, Emmanuel Lecharny <el...@apache.org> wrote:
> Matthieu Riou wrote:
>>
>> Hi guys,
>>
>> What's the take of other mentors and the IPMC on podlings practicing RTC?
>> I'm asking because some seem to see it as a blocker for graduation whereas
>> I
>> see it much more as a development methodology with little community impact
>> and therefore no real influence on graduation. Strong opinions here?
>>
>
> I would bet that most of the Apache project are following the C-T-R scheme
> instead.
>
> IMO, it's up to the project PMC to define the correct strategy, there is
> nothing such a global politic regarding it, AFAIK
+1 It's up to the the PMC for each project.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Emmanuel Lecharny <el...@apache.org>.
Matthieu Riou wrote:
> Hi guys,
>
> What's the take of other mentors and the IPMC on podlings practicing RTC?
> I'm asking because some seem to see it as a blocker for graduation whereas I
> see it much more as a development methodology with little community impact
> and therefore no real influence on graduation. Strong opinions here?
>
I would bet that most of the Apache project are following the C-T-R
scheme instead.
IMO, it's up to the project PMC to define the correct strategy, there is
nothing such a global politic regarding it, AFAIK
> Thanks,
> Matthieu
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Matthieu Riou <ma...@gmail.com>.
On Wed, Nov 11, 2009 at 4:05 PM, Leo Simons <ma...@leosimons.com> wrote:
> On Wed, Nov 11, 2009 at 5:20 PM, Matthieu Riou <ma...@offthelip.org>
> wrote:
> > On Wed, Nov 11, 2009 at 8:31 AM, Daniel Kulp <dk...@apache.org> wrote:
> >>
> >> As Martijn alluded to, I think we'd need some more context as to why and
> >> how they use RTC.
> >>
> > Yes, sorry for the lack of details. The context is Cassandra and they're
> > doing RTC by community choice. They all seem to agree that RTC is the
> best
> > for their own codebase given that some parts of it can be pretty tricky.
> And
> > even committers who aren't too big on RTC generally speaking seem to
> agree
> > that it's working well for them (see [1] for the whole thread, including
> > Paul's objection). So it really seems to be community driven.
> >
> > Thank for the inputs.
>
> Cassandra does about the same thing as hadoop right, where patches go
> into jira for an explicit +1?
>
>
Exactly.
> While I think that's rather painful (if *I* were to do RTC I would
> definitely want to manage it within SVN perhaps with the aid of
> svnmerge.py), I don't think it is _wrong_. If the community really
> wants to do it that way, I say let them. Sorry Paul :)
>
> cheers,
>
> Leo
>
> PS: for the record I've followed cassandra on and off and I would most
> likely +1 on a graduation vote.
>
>
Good to know :)
Matthieu
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Review-Then-Commit
Posted by Leo Simons <ma...@leosimons.com>.
On Wed, Nov 11, 2009 at 5:20 PM, Matthieu Riou <ma...@offthelip.org> wrote:
> On Wed, Nov 11, 2009 at 8:31 AM, Daniel Kulp <dk...@apache.org> wrote:
>>
>> As Martijn alluded to, I think we'd need some more context as to why and
>> how they use RTC.
>>
> Yes, sorry for the lack of details. The context is Cassandra and they're
> doing RTC by community choice. They all seem to agree that RTC is the best
> for their own codebase given that some parts of it can be pretty tricky. And
> even committers who aren't too big on RTC generally speaking seem to agree
> that it's working well for them (see [1] for the whole thread, including
> Paul's objection). So it really seems to be community driven.
>
> Thank for the inputs.
Cassandra does about the same thing as hadoop right, where patches go
into jira for an explicit +1?
While I think that's rather painful (if *I* were to do RTC I would
definitely want to manage it within SVN perhaps with the aid of
svnmerge.py), I don't think it is _wrong_. If the community really
wants to do it that way, I say let them. Sorry Paul :)
cheers,
Leo
PS: for the record I've followed cassandra on and off and I would most
likely +1 on a graduation vote.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Matthieu Riou <ma...@offthelip.org>.
On Wed, Nov 11, 2009 at 8:31 AM, Daniel Kulp <dk...@apache.org> wrote:
>
> As Martijn alluded to, I think we'd need some more context as to why and
> how
> they use RTC.
>
>
Yes, sorry for the lack of details. The context is Cassandra and they're
doing RTC by community choice. They all seem to agree that RTC is the best
for their own codebase given that some parts of it can be pretty tricky. And
even committers who aren't too big on RTC generally speaking seem to agree
that it's working well for them (see [1] for the whole thread, including
Paul's objection). So it really seems to be community driven.
Thank for the inputs.
Matthieu
[1]
http://cassandra.markmail.org/search/?q=#query:list%3Aorg.apache.incubator.cassandra-dev+page:1+mid:4wb5htdz3v6fktue+state:results
If all the reviews are done by a single person because that is what they
> want,
> THAT would be a problem. If the reviews are a community driven thing and
> the
> community thinks that's the best way for the project, that's perfectly
> fine.
>
> The main thing is if the community allows the committers (and ALL the
> committers) to participate in all aspects of the development, including the
> reviews. My main issue with RTC is that it often degrades into a single
> BD
> doing the reviews and pretty much dictating the direction of code.
> Everyone
> else ends up in a "make him happy" mode. That would definitely be a bad
> situation.
>
> Again, if the community is OK with it and it looks like the process is
> working
> and everyone is involved or has the chance to be involved, it's not a
> problem.
>
> Dan
>
>
> On Wed November 11 2009 11:09:39 am Matthieu Riou wrote:
> > Hi guys,
> >
> > What's the take of other mentors and the IPMC on podlings practicing RTC?
> > I'm asking because some seem to see it as a blocker for graduation
> whereas
> > I see it much more as a development methodology with little community
> > impact and therefore no real influence on graduation. Strong opinions
> > here?
> >
> > Thanks,
> > Matthieu
> >
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
Re: Review-Then-Commit
Posted by Matthieu Riou <ma...@gmail.com>.
On Thu, Nov 12, 2009 at 11:01 AM, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 11:44, Matthieu Riou <ma...@gmail.com>
> wrote:
> > On Thu, Nov 12, 2009 at 8:24 AM, ant elder <an...@gmail.com> wrote:
> >
> >> On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans <ee...@rackspace.com>
> wrote:
> >> > On Thu, 2009-11-12 at 07:16 +0000, ant elder wrote:
> >> >> so about 6 months ago to try to help with problems they were having,
> >> >> and since then 99% of the commits have been made by only two people.
> >> >
> >> > I assume you're referring to Jonathan Ellis and myself, and I'm not
> sure
> >> > that's exactly fair. There are only 4 active committers, and of the 4,
> >> > Jonathan and I spend the most time committing patches contributed by
> >> > people who can't, and quite often the "review" was conducted by
> someone
> >> > else who doesn't have commit rights and we are simply acting as a
> proxy.
> >> > This results in a lot of svn commits made by us, for contributions
> that
> >> > are not technically ours.
> >> >
> >> > As a convention, we typically put something like "Patch by $author;
> >> > reviewed by $reviewer for $issue_id" in the change description. I just
> >> > went through the commits scraping out those messages and it looks like
> >> > Jonathan and I account for a little more than 60%, not 99%.
> >> >
> >> > --
> >> > Eric Evans
> >> > eevans@rackspace.com
> >> >
> >>
> >> So about 40% of the committed code is coming from others and reviewed
> >> by others - great - why not make some of those others committers?
> >>
> >>
> > That's pretty much what they're doing about right now but as you know, it
> > takes some time to establish a good patch history. I really don't thin
> > Cassandra should be accused of being bad at attracting and voting in new
> > committers. Given how they started they're definitely better at it than
> most
> > podlings.
>
> Easy there... nobody is accusing anybody of anything.
>
>
Ah, sorry if that came across too strongly, I didn't mean it that way. I
just meant that I haven't seen a problem in the way Cassandra was attracting
committers. So that was definitely discussion as well on my side :)
Matthieu
> You asked a question, and people have answered. Some of those answers
> have come with concerns. That generates discussion.
>
> I think it is good for any project to review why it is operating
> *differently* than the majority of projects here at the ASF. Why is it
> "special"? Are those special considerations actually masking a problem
> underneath? Are those special processes going to hinder the free and
> inclusive participation and community-building that we like to see in
> our projects?
>
> It's fair to ask those questions, especially of a podling. But please
> don't misconstrue discussion as accusation.
>
> Cheers,
> -g
>
Re: Review-Then-Commit
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Nov 12, 2009 at 11:44, Matthieu Riou <ma...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 8:24 AM, ant elder <an...@gmail.com> wrote:
>
>> On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans <ee...@rackspace.com> wrote:
>> > On Thu, 2009-11-12 at 07:16 +0000, ant elder wrote:
>> >> so about 6 months ago to try to help with problems they were having,
>> >> and since then 99% of the commits have been made by only two people.
>> >
>> > I assume you're referring to Jonathan Ellis and myself, and I'm not sure
>> > that's exactly fair. There are only 4 active committers, and of the 4,
>> > Jonathan and I spend the most time committing patches contributed by
>> > people who can't, and quite often the "review" was conducted by someone
>> > else who doesn't have commit rights and we are simply acting as a proxy.
>> > This results in a lot of svn commits made by us, for contributions that
>> > are not technically ours.
>> >
>> > As a convention, we typically put something like "Patch by $author;
>> > reviewed by $reviewer for $issue_id" in the change description. I just
>> > went through the commits scraping out those messages and it looks like
>> > Jonathan and I account for a little more than 60%, not 99%.
>> >
>> > --
>> > Eric Evans
>> > eevans@rackspace.com
>> >
>>
>> So about 40% of the committed code is coming from others and reviewed
>> by others - great - why not make some of those others committers?
>>
>>
> That's pretty much what they're doing about right now but as you know, it
> takes some time to establish a good patch history. I really don't thin
> Cassandra should be accused of being bad at attracting and voting in new
> committers. Given how they started they're definitely better at it than most
> podlings.
Easy there... nobody is accusing anybody of anything.
You asked a question, and people have answered. Some of those answers
have come with concerns. That generates discussion.
I think it is good for any project to review why it is operating
*differently* than the majority of projects here at the ASF. Why is it
"special"? Are those special considerations actually masking a problem
underneath? Are those special processes going to hinder the free and
inclusive participation and community-building that we like to see in
our projects?
It's fair to ask those questions, especially of a podling. But please
don't misconstrue discussion as accusation.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Matthieu Riou <ma...@gmail.com>.
On Thu, Nov 12, 2009 at 8:24 AM, ant elder <an...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans <ee...@rackspace.com> wrote:
> > On Thu, 2009-11-12 at 07:16 +0000, ant elder wrote:
> >> so about 6 months ago to try to help with problems they were having,
> >> and since then 99% of the commits have been made by only two people.
> >
> > I assume you're referring to Jonathan Ellis and myself, and I'm not sure
> > that's exactly fair. There are only 4 active committers, and of the 4,
> > Jonathan and I spend the most time committing patches contributed by
> > people who can't, and quite often the "review" was conducted by someone
> > else who doesn't have commit rights and we are simply acting as a proxy.
> > This results in a lot of svn commits made by us, for contributions that
> > are not technically ours.
> >
> > As a convention, we typically put something like "Patch by $author;
> > reviewed by $reviewer for $issue_id" in the change description. I just
> > went through the commits scraping out those messages and it looks like
> > Jonathan and I account for a little more than 60%, not 99%.
> >
> > --
> > Eric Evans
> > eevans@rackspace.com
> >
>
> So about 40% of the committed code is coming from others and reviewed
> by others - great - why not make some of those others committers?
>
>
That's pretty much what they're doing about right now but as you know, it
takes some time to establish a good patch history. I really don't thin
Cassandra should be accused of being bad at attracting and voting in new
committers. Given how they started they're definitely better at it than most
podlings.
Matthieu
> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Review-Then-Commit
Posted by Matthieu Riou <ma...@gmail.com>.
On Thu, Nov 12, 2009 at 8:55 AM, ant elder <an...@apache.org> wrote:
> On Thu, Nov 12, 2009 at 4:36 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>
> > On Thu, Nov 12, 2009 at 10:24 AM, ant elder <an...@gmail.com> wrote:
> >> So about 40% of the committed code is coming from others and reviewed
> >> by others - great - why not make some of those others committers?
> >
> > It's a long tail sort of thing.
> >
> > We follow the convention Johan suggested of assigning the Jira issue
> > to the author of the change, so e.g. for 05 the contributions look
> > like this:
> https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=12314040&issueStatus=all&selectedProjectId=12310865&reportKey=com.sourcelabs.jira.plugin.report.contributions%3Acontributionreport&Next=Next
> >
>
> That JIRA report shows a range of contributors that many TLPs would be
> envious of, and it shows a quite different picture from the commit
> history, eg:
>
>
> http://www.svnsearch.org/svnsearch/repos/ASF/search?from=20090801&to=20091231&path=%2Fincubator%2Fcassandra
>
>
Evan and Jonathan are the most active committers but still I can see quite a
few:
patch by Jaakko Laine and jbellis
patch by Scott White; reviewed by Brandon Williams
patch by Jaakko Laine; reviewed by jbellis
patch by Gary Dusbabek; reviewed by eevans
And that's only going as far as 2 days ago. So is the problem only what the
commit log looks like if you only look at who committed the patch?
Matthieu
It would be great to get more of those contributors actually doing the
> commits though, maybe modifying the current commit process as is being
> suggested in this thread could help get that to happen.
>
> ...ant
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Review-Then-Commit
Posted by ant elder <an...@apache.org>.
On Thu, Nov 12, 2009 at 4:36 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 10:24 AM, ant elder <an...@gmail.com> wrote:
>> So about 40% of the committed code is coming from others and reviewed
>> by others - great - why not make some of those others committers?
>
> It's a long tail sort of thing.
>
> We follow the convention Johan suggested of assigning the Jira issue
> to the author of the change, so e.g. for 05 the contributions look
> like this: https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=12314040&issueStatus=all&selectedProjectId=12310865&reportKey=com.sourcelabs.jira.plugin.report.contributions%3Acontributionreport&Next=Next
>
That JIRA report shows a range of contributors that many TLPs would be
envious of, and it shows a quite different picture from the commit
history, eg:
http://www.svnsearch.org/svnsearch/repos/ASF/search?from=20090801&to=20091231&path=%2Fincubator%2Fcassandra
It would be great to get more of those contributors actually doing the
commits though, maybe modifying the current commit process as is being
suggested in this thread could help get that to happen.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Nov 12, 2009 at 10:24 AM, ant elder <an...@gmail.com> wrote:
> So about 40% of the committed code is coming from others and reviewed
> by others - great - why not make some of those others committers?
It's a long tail sort of thing.
We follow the convention Johan suggested of assigning the Jira issue
to the author of the change, so e.g. for 05 the contributions look
like this: https://issues.apache.org/jira/secure/ConfigureReport.jspa?versionId=12314040&issueStatus=all&selectedProjectId=12310865&reportKey=com.sourcelabs.jira.plugin.report.contributions%3Acontributionreport&Next=Next
The main name that stands out there to me that is not already a
committer is Gary Dusbabek, who has been working on Cassandra for
about a week now but who I expect will be nominated soon at this rate.
The other top contributors are already committers.
-Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by ant elder <an...@gmail.com>.
On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans <ee...@rackspace.com> wrote:
> On Thu, 2009-11-12 at 07:16 +0000, ant elder wrote:
>> so about 6 months ago to try to help with problems they were having,
>> and since then 99% of the commits have been made by only two people.
>
> I assume you're referring to Jonathan Ellis and myself, and I'm not sure
> that's exactly fair. There are only 4 active committers, and of the 4,
> Jonathan and I spend the most time committing patches contributed by
> people who can't, and quite often the "review" was conducted by someone
> else who doesn't have commit rights and we are simply acting as a proxy.
> This results in a lot of svn commits made by us, for contributions that
> are not technically ours.
>
> As a convention, we typically put something like "Patch by $author;
> reviewed by $reviewer for $issue_id" in the change description. I just
> went through the commits scraping out those messages and it looks like
> Jonathan and I account for a little more than 60%, not 99%.
>
> --
> Eric Evans
> eevans@rackspace.com
>
So about 40% of the committed code is coming from others and reviewed
by others - great - why not make some of those others committers?
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2009-11-12 at 07:16 +0000, ant elder wrote:
> so about 6 months ago to try to help with problems they were having,
> and since then 99% of the commits have been made by only two people.
I assume you're referring to Jonathan Ellis and myself, and I'm not sure
that's exactly fair. There are only 4 active committers, and of the 4,
Jonathan and I spend the most time committing patches contributed by
people who can't, and quite often the "review" was conducted by someone
else who doesn't have commit rights and we are simply acting as a proxy.
This results in a lot of svn commits made by us, for contributions that
are not technically ours.
As a convention, we typically put something like "Patch by $author;
reviewed by $reviewer for $issue_id" in the change description. I just
went through the commits scraping out those messages and it looks like
Jonathan and I account for a little more than 60%, not 99%.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by ant elder <an...@gmail.com>.
On Wed, Nov 11, 2009 at 4:31 PM, Daniel Kulp <dk...@apache.org> wrote:
>
> As Martijn alluded to, I think we'd need some more context as to why and how
> they use RTC.
>
This appears to be where it came from:
http://markmail.org/message/d45dmasuwnda25wd
so about 6 months ago to try to help with problems they were having,
and since then 99% of the commits have been made by only two people.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Daniel Kulp <dk...@apache.org>.
As Martijn alluded to, I think we'd need some more context as to why and how
they use RTC.
If all the reviews are done by a single person because that is what they want,
THAT would be a problem. If the reviews are a community driven thing and the
community thinks that's the best way for the project, that's perfectly fine.
The main thing is if the community allows the committers (and ALL the
committers) to participate in all aspects of the development, including the
reviews. My main issue with RTC is that it often degrades into a single BD
doing the reviews and pretty much dictating the direction of code. Everyone
else ends up in a "make him happy" mode. That would definitely be a bad
situation.
Again, if the community is OK with it and it looks like the process is working
and everyone is involved or has the chance to be involved, it's not a problem.
Dan
On Wed November 11 2009 11:09:39 am Matthieu Riou wrote:
> Hi guys,
>
> What's the take of other mentors and the IPMC on podlings practicing RTC?
> I'm asking because some seem to see it as a blocker for graduation whereas
> I see it much more as a development methodology with little community
> impact and therefore no real influence on graduation. Strong opinions
> here?
>
> Thanks,
> Matthieu
>
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Martijn Dashorst <ma...@gmail.com>.
As long as the community is not divided on the issue whether to
practice RTC vs CTR, I see no blocker for graduation.
That is: as long as RTC was not installed to mitigate problems inside
the community. If that is the case, the community may still be broken,
with the underlying issue mopped under the carpet.
Martijn
On Wed, Nov 11, 2009 at 5:09 PM, Matthieu Riou <ma...@offthelip.org> wrote:
> Hi guys,
>
> What's the take of other mentors and the IPMC on podlings practicing RTC?
> I'm asking because some seem to see it as a blocker for graduation whereas I
> see it much more as a development methodology with little community impact
> and therefore no real influence on graduation. Strong opinions here?
>
> Thanks,
> Matthieu
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Bruce Snyder <br...@gmail.com>.
On Wed, Nov 11, 2009 at 8:16 PM, Greg Stein <gs...@gmail.com> wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of
> ideas, experimentation, evolution, and creativity. It is a damper on
> expressivity. You maneuver bureaucracy to get a change in. CTR is
> about making a change and discussing it. But you get *forward
> progress*.
>
> I also feel that RTC will tend towards *exclusivity* rather than the
> Apache ideal of *inclusivity*. That initial review is a social and
> mental burden for new committers. People are afraid enough of
> submitting patches and trying to join into a development community,
> without making them run through a front-loaded process.
>
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
>
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.
+1 Very well said, Greg.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Emmanuel Lecharny <el...@apache.org>.
Michael Wechner wrote:
> Ian Boston schrieb:
>>
>>
>> not least because committed mistakes demand fixing by the committer
>> and then anyone who can fix the bug. The only downside is that
>> occasionally trunk wont build/run and if trunk is close to production
>> that probably matters.
>
> I think another downside is, that (maybe depending on the community)
> in reality a proper review often doesn't happen in the case
> of CTR and in the case of performance/scalability this can be very
> bad, because the actual problems are often detected
> at a very late stage and then it can be very hard to solve these
> issues, because the code has already advanced too far.
>
> I see the postive sides of CTR re community and progress, but I think
> it requires some additional rules, guidelines
> in order to make it work.
As a matter of fact, at Directory, we are using CTR since the beginning,
and we have had to define those rules. It's pretty easy :
- if it does not compile locally, don't commit
- when you commit, always try to do it in a way a simple revert restore
the previous state
- when doing some heavy refactoring, do it in a branch
- add some integration tests early in the process
- for new committers, check their commits until they are trustable
- define some code rules (syntax, comments, etc) followed by everyone.
That's pretty much it, and it work quite well considering the project
size (325 000 slocs as of today...)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Michael Wechner <mi...@wyona.com>.
Ian Boston schrieb:
>
>
> not least because committed mistakes demand fixing by the committer
> and then anyone who can fix the bug. The only downside is that
> occasionally trunk wont build/run and if trunk is close to production
> that probably matters.
I think another downside is, that (maybe depending on the community) in
reality a proper review often doesn't happen in the case
of CTR and in the case of performance/scalability this can be very bad,
because the actual problems are often detected
at a very late stage and then it can be very hard to solve these issues,
because the code has already advanced too far.
I see the postive sides of CTR re community and progress, but I think
it requires some additional rules, guidelines
in order to make it work.
Cheers
Michael
>
> Shindig is mostly RTC, and was very close to big production.
> Sling is mostly CTR
>
> Ian
>
>
>>
>> Cheers,
>> -g
>>
>> On Wed, Nov 11, 2009 at 11:09, Matthieu Riou <ma...@offthelip.org>
>> wrote:
>>> Hi guys,
>>>
>>> What's the take of other mentors and the IPMC on podlings practicing
>>> RTC?
>>> I'm asking because some seem to see it as a blocker for graduation
>>> whereas I
>>> see it much more as a development methodology with little community
>>> impact
>>> and therefore no real influence on graduation. Strong opinions here?
>>>
>>> Thanks,
>>> Matthieu
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Ian Boston <ie...@tfd.co.uk>.
On 12 Nov 2009, at 03:16, Greg Stein wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of
> ideas, experimentation, evolution, and creativity. It is a damper on
> expressivity. You maneuver bureaucracy to get a change in. CTR is
> about making a change and discussing it. But you get *forward
> progress*.
>
> I also feel that RTC will tend towards *exclusivity* rather than the
> Apache ideal of *inclusivity*. That initial review is a social and
> mental burden for new committers. People are afraid enough of
> submitting patches and trying to join into a development community,
> without making them run through a front-loaded process.
>
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
>
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.
+1, having experienced both,
IMVHO
RTC shrinks a community to a core team of dedicated and highly
knowledgeable committers.
CTR expands and educates a community
not least because committed mistakes demand fixing by the committer
and then anyone who can fix the bug. The only downside is that
occasionally trunk wont build/run and if trunk is close to production
that probably matters.
Shindig is mostly RTC, and was very close to big production.
Sling is mostly CTR
Ian
>
> Cheers,
> -g
>
> On Wed, Nov 11, 2009 at 11:09, Matthieu Riou
> <ma...@offthelip.org> wrote:
>> Hi guys,
>>
>> What's the take of other mentors and the IPMC on podlings
>> practicing RTC?
>> I'm asking because some seem to see it as a blocker for graduation
>> whereas I
>> see it much more as a development methodology with little community
>> impact
>> and therefore no real influence on graduation. Strong opinions here?
>>
>> Thanks,
>> Matthieu
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Matthieu Riou <ma...@gmail.com>.
On Thu, Nov 12, 2009 at 8:36 AM, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 11:32, Eric Evans <ee...@rackspace.com> wrote:
> >...
> > I agree with this, and as a Cassandra committer I have in the past
> > protested our use of RTC. However, the current work-flow *in practice*
> > is more about having someone, anyone, give changes a once over (making
> > sure they build, that tests pass, that they do what they claim, etc),
> > before committing.
> >
> > I agree with you, but tabled my protest because in practice what we have
> > is working, doesn't seem to be a barrier to contribution, and everyone
> > seems happy with it (even the casual contributors).
>
> I wouldn't say "everyone". This whole thread started because at least
> one person is not happy with it.
>
>
And that person isn't a committer but a user. Note that I agree with some of
your remarks (and his), my point though is that it's up to the PMC to figure
it out and it shouldn't be more than an advice for them to take into
account. Not a graduation blocker.
> > I actually work with
> > these people on a daily basis, and I trust that when/if it actually does
> > become a problem, that people will be open to changing it.
>
> This actually scares me a bit. That a discussion of methodology is
> happening among a few people at work, rather than among everybody on
> the mailing list.
>
>
I think the "work" above was work-as-in-developing, not
work-as-in-workplace.
Matthieu
> >...
> >> My opinion is that it is very unfortunate that Cassandra feels that it
> >> cannot trust its developers with a CTR model, and pushes RTC as its
> >> methodology. The group-mind smashes down the creativity of the
> >> individual, excited, free-thinking contributor.
> >
> > Cassandra is in incubation, so by all means, use the IPMC group-mind to
> > smash the individual, excited, and free-thinking Cassandra contributors
> > into submission.
>
> My opinion was asked, and I answered. Please don't ascribe more to it than
> that.
>
> Cheers,
> -g
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Review-Then-Commit
Posted by Jonathan Ellis <jb...@gmail.com>.
On Thu, Nov 12, 2009 at 10:36 AM, Greg Stein <gs...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 11:32, Eric Evans <ee...@rackspace.com> wrote:
>> I agree with you, but tabled my protest because in practice what we have
>> is working, doesn't seem to be a barrier to contribution, and everyone
>> seems happy with it (even the casual contributors).
>
> I wouldn't say "everyone". This whole thread started because at least
> one person is not happy with it.
We had a long discussion about this on cassandra-dev. If I remember
correctly, everyone who actually contributes code to the project
expressed a preference for the current lightweight RTC appraoch.
-Jonathan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Branko Čibej <br...@xbc.nu>.
Eric Evans wrote:
> Sure, but the IPMC is in a position of power, and can impose it's will
> upon the project (including CTR vs. RTC), right?
>
I have no clue whether the IPMC can impose such a decision. But I'm
very, very certain that it should not even consider trying. It's better
to ask the podling's PMC to address concerns and let them work it out,
than simply telling them that "we see this problem, and here's how you
will fix it." That would be rather counterproductive, the idea is to
ensure the project can live independently once it has graduated.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2009-11-12 at 11:36 -0500, Greg Stein wrote:
> > I agree with you, but tabled my protest because in practice what we
> > have is working, doesn't seem to be a barrier to contribution, and >
> > everyone seems happy with it (even the casual contributors).
>
> I wouldn't say "everyone". This whole thread started because at least
> one person is not happy with it.
You're right, I wasn't being very precise with my wording. "Overwhelming
majority", or "people actually doing the work" would have been better.
> > I actually work with these people on a daily basis, and I trust that
> > when/if it actually does become a problem, that people will be open
> > to changing it.
>
> This actually scares me a bit. That a discussion of methodology is
> happening among a few people at work, rather than among everybody on
> the mailing list.
Maybe this is another case of me not being precise enough with my
wording.
I routinely collaborate with the members of the Cassandra community, on
IRC and mailing lists, (not at my place of employment).
> >> My opinion is that it is very unfortunate that Cassandra feels that
> >> it cannot trust its developers with a CTR model, and pushes RTC as
> >> its methodology. The group-mind smashes down the creativity of the
> >> individual, excited, free-thinking contributor.
> >
> > Cassandra is in incubation, so by all means, use the IPMC group-mind
> > to smash the individual, excited, and free-thinking Cassandra
> > contributors into submission.
>
> My opinion was asked, and I answered. Please don't ascribe more to it
> than that.
Sure, but the IPMC is in a position of power, and can impose it's will
upon the project (including CTR vs. RTC), right?
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Nov 12, 2009 at 11:32, Eric Evans <ee...@rackspace.com> wrote:
>...
> I agree with this, and as a Cassandra committer I have in the past
> protested our use of RTC. However, the current work-flow *in practice*
> is more about having someone, anyone, give changes a once over (making
> sure they build, that tests pass, that they do what they claim, etc),
> before committing.
>
> I agree with you, but tabled my protest because in practice what we have
> is working, doesn't seem to be a barrier to contribution, and everyone
> seems happy with it (even the casual contributors).
I wouldn't say "everyone". This whole thread started because at least
one person is not happy with it.
> I actually work with
> these people on a daily basis, and I trust that when/if it actually does
> become a problem, that people will be open to changing it.
This actually scares me a bit. That a discussion of methodology is
happening among a few people at work, rather than among everybody on
the mailing list.
>...
>> My opinion is that it is very unfortunate that Cassandra feels that it
>> cannot trust its developers with a CTR model, and pushes RTC as its
>> methodology. The group-mind smashes down the creativity of the
>> individual, excited, free-thinking contributor.
>
> Cassandra is in incubation, so by all means, use the IPMC group-mind to
> smash the individual, excited, and free-thinking Cassandra contributors
> into submission.
My opinion was asked, and I answered. Please don't ascribe more to it than that.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Eric Evans <ee...@rackspace.com>.
On Wed, 2009-11-11 at 22:16 -0500, Greg Stein wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of
> ideas, experimentation, evolution, and creativity. It is a damper on
> expressivity. You maneuver bureaucracy to get a change in. CTR is
> about making a change and discussing it. But you get *forward
> progress*.
>
> I also feel that RTC will tend towards *exclusivity* rather than the
> Apache ideal of *inclusivity*. That initial review is a social and
> mental burden for new committers. People are afraid enough of
> submitting patches and trying to join into a development community,
> without making them run through a front-loaded process.
I agree with this, and as a Cassandra committer I have in the past
protested our use of RTC. However, the current work-flow *in practice*
is more about having someone, anyone, give changes a once over (making
sure they build, that tests pass, that they do what they claim, etc),
before committing.
I agree with you, but tabled my protest because in practice what we have
is working, doesn't seem to be a barrier to contribution, and everyone
seems happy with it (even the casual contributors). I actually work with
these people on a daily basis, and I trust that when/if it actually does
become a problem, that people will be open to changing it.
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
>
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.
Cassandra is in incubation, so by all means, use the IPMC group-mind to
smash the individual, excited, and free-thinking Cassandra contributors
into submission.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Paul Querna <pa...@querna.org>.
On Wed, Nov 11, 2009 at 7:16 PM, Greg Stein <gs...@gmail.com> wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of
> ideas, experimentation, evolution, and creativity. It is a damper on
> expressivity. You maneuver bureaucracy to get a change in. CTR is
> about making a change and discussing it. But you get *forward
> progress*.
>
> I also feel that RTC will tend towards *exclusivity* rather than the
> Apache ideal of *inclusivity*. That initial review is a social and
> mental burden for new committers. People are afraid enough of
> submitting patches and trying to join into a development community,
> without making them run through a front-loaded process.
>
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
>
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.
+1, thanks for writing this all out Greg, your thoughts about RTC for
'trunk' type branches is exactly inline with my own -- it doesn't mean
there should be a decrease in end quality, but it definitely does
stifle several potential aspects of the community. This is my concern
with regards to Cassandra, based on my own experiences with CTR/RTC at
Apache and other projects.
Thanks,
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by ant elder <an...@gmail.com>.
I agree with that. And before graduation I think it might be worth
trying to get CTR used more, they do seem open this -
http://markmail.org/message/i255ekzxpuesow44
...ant
On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein <gs...@gmail.com> wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of
> ideas, experimentation, evolution, and creativity. It is a damper on
> expressivity. You maneuver bureaucracy to get a change in. CTR is
> about making a change and discussing it. But you get *forward
> progress*.
>
> I also feel that RTC will tend towards *exclusivity* rather than the
> Apache ideal of *inclusivity*. That initial review is a social and
> mental burden for new committers. People are afraid enough of
> submitting patches and trying to join into a development community,
> without making them run through a front-loaded process.
>
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
>
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.
>
> Cheers,
> -g
>
> On Wed, Nov 11, 2009 at 11:09, Matthieu Riou <ma...@offthelip.org> wrote:
>> Hi guys,
>>
>> What's the take of other mentors and the IPMC on podlings practicing RTC?
>> I'm asking because some seem to see it as a blocker for graduation whereas I
>> see it much more as a development methodology with little community impact
>> and therefore no real influence on graduation. Strong opinions here?
>>
>> Thanks,
>> Matthieu
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Doug Cutting <cu...@apache.org>.
Niclas Hedhman wrote:
> I am curious (never worked in a RTC environment);
>
> Does that mean that people turn down offers of commit rights? Does it
> mean that less commit rights are offered? Does it mean that commit
> rights are offered to those that do reviews even if they don't write
> much code?
No to all, in my experience.
Code reviews generally improve code quality. Every change should be
reviewed, regardless of whether RTC or CTR are used. RTC simply
formalizes the review step of the process.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sat, Nov 14, 2009 at 5:30 AM, Doug Cutting <cu...@apache.org> wrote:
> Aidan Skinner wrote:
>>
>> I'd flip this around and look at it from the PoV of a
>> not-yet-committer. RTC means everybody goes through basically the same
>> process - (raise jira), hack, submit patch, patch gets reviewed, patch
>> gets committed regardless of whether they have a commit bit or not.
>
> +1 With RTC as I've practiced it, becoming a committer doesn't so much give
> a privilege as a duty: committers are expected to review and commit patches
> promptly.
I am curious (never worked in a RTC environment);
Does that mean that people turn down offers of commit rights? Does it
mean that less commit rights are offered? Does it mean that commit
rights are offered to those that do reviews even if they don't write
much code?
I mean, if I can see only downsides, then why should I bother? Perhaps
bragging rights to friends are enough for first-timers, but hardly to
people that have been around the block a few times...
Cheers
--
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/2qq9er
I work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Doug Cutting <cu...@apache.org>.
Aidan Skinner wrote:
> I'd flip this around and look at it from the PoV of a
> not-yet-committer. RTC means everybody goes through basically the same
> process - (raise jira), hack, submit patch, patch gets reviewed, patch
> gets committed regardless of whether they have a commit bit or not.
+1 With RTC as I've practiced it, becoming a committer doesn't so much
give a privilege as a duty: committers are expected to review and commit
patches promptly.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Greg Stein <gs...@gmail.com>.
Yup. We have all had different experiences, and I certainly
acknowledge it is possible to have a successful RTC model in place.
The real problem is that there is always a success story for any
position. "See? It works here." And there are *so* many factors that
go into that success, beyond the simple tradeoff of CTR vs RTC. So it
is very difficult to objectively compare/contrast models.
We can sit around and throw out our own experiences, but those won't
necessarily apply to Cassandra.
Personally, I'm suspect of any RTC here at the ASF. In this specific
case, it sounds like more committers and a return to CTR could be
good. The 99% commit statistic (no matter *how* you want to break down
the patch-from-others) is worrying. Why aren't other committers
present and participating in that patch application? (or their own
work)
btw, if a community is not running smoothly, then referring people to
git-scm is totally the wrong solution: fix the community, rather than
sending people off to their own corners with their own branches, all
working independently rather than together. My biggest problem with
Git isn't the tech (which is great!), but the social aspects of a
default workflow that stresses individualism rather than cooperation.
Cheers,
-g
On Thu, Nov 12, 2009 at 17:46, Aidan Skinner <ai...@gmail.com> wrote:
> On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein <gs...@gmail.com> wrote:
>
>> Not a "strong opinion", but I think that RTC hampers the free-flow of
>> ideas, experimentation, evolution, and creativity. It is a damper on
>> expressivity. You maneuver bureaucracy to get a change in. CTR is
>> about making a change and discussing it. But you get *forward
>> progress*.
>
> I think this entirely depends on how quickly you get an R. I've worked
> for $BIGCOs that do CTR and have really stifling cultures and
> $SPUNKYSTARTUPs that do RTC and have huge forward momentum. Momentum
> which is more sustainable because the explicit review means at least
> one other person knows what it is that you're doing so there's some
> instant knowledge sharing to reduce the risk of blind alleys and the
> bus factor.
>
>> I also feel that RTC will tend towards *exclusivity* rather than the
>> Apache ideal of *inclusivity*. That initial review is a social and
>> mental burden for new committers. People are afraid enough of
>> submitting patches and trying to join into a development community,
>> without making them run through a front-loaded process.
>
> I'd flip this around and look at it from the PoV of a
> not-yet-committer. RTC means everybody goes through basically the same
> process - (raise jira), hack, submit patch, patch gets reviewed, patch
> gets committed regardless of whether they have a commit bit or not.
>
> CTR means there is a qualitative difference in workflows between
> committers and non-committers.
>
>> I've participated in both styles of development. RTC is *stifling*. I
>> would never want to see that in any Apache community for its routine
>> development (branch releases are another matter).
>
> I'm sorry you found it that way, I don't think it has to be that way though. :/
>
>> My opinion is that it is very unfortunate that Cassandra feels that it
>> cannot trust its developers with a CTR model, and pushes RTC as its
>> methodology. The group-mind smashes down the creativity of the
>> individual, excited, free-thinking contributor.
>
> I think that sort of group mentality is problematic regardless of
> review model, it's perhaps a bit more commonly found in RTC but I
> don't think it's inherent to the system (you can insert your own Monty
> Python reference here if you want).
>
> The main benefit I've always found for RTC (beside being slightly
> flatter, as outlined above), is that it means that the review actually
> happens and can be seen to have happened. CTR often falls by the
> wayside, even with tooling. For Qpid 0.5 we used Jira workflow to try
> and support this and still ended up with something like 50 jiras in
> "ready to review" state. While it's possible that somebody read the
> code and couldn't be bothered to click the button, I think it's much
> more likely that they're basically unreviewed. There's also a number
> of Jiras that are essentially review comments that have been kicking
> around for ages.
>
> A number of large, venerable projects run with RTC for a number of
> reasons. I know a lot of people dislike it due to prior bad
> experience, that it stifles them, holds up progress etc. To them I say
> http://git-scm.com ;)
>
> - Aidan
> --
> Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
> "A witty saying proves nothing" - Voltaire
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Aidan Skinner <ai...@gmail.com>.
On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein <gs...@gmail.com> wrote:
> Not a "strong opinion", but I think that RTC hampers the free-flow of
> ideas, experimentation, evolution, and creativity. It is a damper on
> expressivity. You maneuver bureaucracy to get a change in. CTR is
> about making a change and discussing it. But you get *forward
> progress*.
I think this entirely depends on how quickly you get an R. I've worked
for $BIGCOs that do CTR and have really stifling cultures and
$SPUNKYSTARTUPs that do RTC and have huge forward momentum. Momentum
which is more sustainable because the explicit review means at least
one other person knows what it is that you're doing so there's some
instant knowledge sharing to reduce the risk of blind alleys and the
bus factor.
> I also feel that RTC will tend towards *exclusivity* rather than the
> Apache ideal of *inclusivity*. That initial review is a social and
> mental burden for new committers. People are afraid enough of
> submitting patches and trying to join into a development community,
> without making them run through a front-loaded process.
I'd flip this around and look at it from the PoV of a
not-yet-committer. RTC means everybody goes through basically the same
process - (raise jira), hack, submit patch, patch gets reviewed, patch
gets committed regardless of whether they have a commit bit or not.
CTR means there is a qualitative difference in workflows between
committers and non-committers.
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
I'm sorry you found it that way, I don't think it has to be that way though. :/
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.
I think that sort of group mentality is problematic regardless of
review model, it's perhaps a bit more commonly found in RTC but I
don't think it's inherent to the system (you can insert your own Monty
Python reference here if you want).
The main benefit I've always found for RTC (beside being slightly
flatter, as outlined above), is that it means that the review actually
happens and can be seen to have happened. CTR often falls by the
wayside, even with tooling. For Qpid 0.5 we used Jira workflow to try
and support this and still ended up with something like 50 jiras in
"ready to review" state. While it's possible that somebody read the
code and couldn't be bothered to click the button, I think it's much
more likely that they're basically unreviewed. There's also a number
of Jiras that are essentially review comments that have been kicking
around for ages.
A number of large, venerable projects run with RTC for a number of
reasons. I know a lot of people dislike it due to prior bad
experience, that it stifles them, holds up progress etc. To them I say
http://git-scm.com ;)
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Doug Cutting <cu...@apache.org>.
Justin Erenkrantz wrote:
> As I understood Owen's "Intro to Hadoop" talk at AC, Hadoop has
> changed their methodology lately to CTR and found it to work far
> better. (Duh.) -- justin
Hadoop uses RTC.
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Eric Evans <ee...@rackspace.com>.
On Thu, 2009-11-12 at 08:44 +0100, Justin Erenkrantz wrote:
> I think part of Cassandra's problem is that they do releases directly
> from trunk and don't have a 'stable' et al branch.
No, this isn't (has never been) true.
https://svn.apache.org/repos/asf/incubator/cassandra/branches/
The cassandra-0.4 branch alone has seen 3 releases so far.
--
Eric Evans
eevans@rackspace.com
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Thu, Nov 12, 2009 at 4:16 AM, Greg Stein <gs...@gmail.com> wrote:
> I've participated in both styles of development. RTC is *stifling*. I
> would never want to see that in any Apache community for its routine
> development (branch releases are another matter).
>
> My opinion is that it is very unfortunate that Cassandra feels that it
> cannot trust its developers with a CTR model, and pushes RTC as its
> methodology. The group-mind smashes down the creativity of the
> individual, excited, free-thinking contributor.
+1.
I think part of Cassandra's problem is that they do releases directly
from trunk and don't have a 'stable' et al branch.
As I understood Owen's "Intro to Hadoop" talk at AC, Hadoop has
changed their methodology lately to CTR and found it to work far
better. (Duh.) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Review-Then-Commit
Posted by Greg Stein <gs...@gmail.com>.
Not a "strong opinion", but I think that RTC hampers the free-flow of
ideas, experimentation, evolution, and creativity. It is a damper on
expressivity. You maneuver bureaucracy to get a change in. CTR is
about making a change and discussing it. But you get *forward
progress*.
I also feel that RTC will tend towards *exclusivity* rather than the
Apache ideal of *inclusivity*. That initial review is a social and
mental burden for new committers. People are afraid enough of
submitting patches and trying to join into a development community,
without making them run through a front-loaded process.
I've participated in both styles of development. RTC is *stifling*. I
would never want to see that in any Apache community for its routine
development (branch releases are another matter).
My opinion is that it is very unfortunate that Cassandra feels that it
cannot trust its developers with a CTR model, and pushes RTC as its
methodology. The group-mind smashes down the creativity of the
individual, excited, free-thinking contributor.
Cheers,
-g
On Wed, Nov 11, 2009 at 11:09, Matthieu Riou <ma...@offthelip.org> wrote:
> Hi guys,
>
> What's the take of other mentors and the IPMC on podlings practicing RTC?
> I'm asking because some seem to see it as a blocker for graduation whereas I
> see it much more as a development methodology with little community impact
> and therefore no real influence on graduation. Strong opinions here?
>
> Thanks,
> Matthieu
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org