Re: Review-Then-Commit
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Sat, Nov 14, 2009 at 5:30 AM, Doug Cutting cutt...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 matth...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 matth...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 7:16 PM, Greg Stein gst...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 8:16 PM, Greg Stein gst...@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)u8...@4vyy95R\F)R=6-E+G-N61ED\!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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, 2009-11-12 at 07:16 +, 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 eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 8:24 AM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, 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 eev...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 10:36 AM, Greg Stein gst...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:32, Eric Evans eev...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 11:32, Eric Evans eev...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, 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 eev...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 10:24 AM, ant elder ant.el...@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=12314040issueStatus=allselectedProjectId=12310865reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 8:36 AM, Greg Stein gst...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:32, Eric Evans eev...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 4:36 PM, Jonathan Ellis jbel...@gmail.com wrote: On Thu, Nov 12, 2009 at 10:24 AM, ant elder ant.el...@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=12314040issueStatus=allselectedProjectId=12310865reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=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=20090801to=20091231path=%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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 eev...@rackspace.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 8:55 AM, ant elder antel...@apache.org wrote: On Thu, Nov 12, 2009 at 4:36 PM, Jonathan Ellis jbel...@gmail.com wrote: On Thu, Nov 12, 2009 at 10:24 AM, ant elder ant.el...@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=12314040issueStatus=allselectedProjectId=12310865reportKey=com.sourcelabs.jira.plugin.report.contributions%3AcontributionreportNext=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=20090801to=20091231path=%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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 11:44, Matthieu Riou matthieu.r...@gmail.com wrote: On Thu, Nov 12, 2009 at 8:24 AM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, 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 eev...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 11:01 AM, Greg Stein gst...@gmail.com wrote: On Thu, Nov 12, 2009 at 11:44, Matthieu Riou matthieu.r...@gmail.com wrote: On Thu, Nov 12, 2009 at 8:24 AM, ant elder ant.el...@gmail.com wrote: On Thu, Nov 12, 2009 at 4:12 PM, Eric Evans eev...@rackspace.com wrote: On Thu, 2009-11-12 at 07:16 +, 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 eev...@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
On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein gst...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 aidan.skin...@gmail.com wrote: On Thu, Nov 12, 2009 at 3:16 AM, Greg Stein gst...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
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
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 matth...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 dk...@apache.org http://www.dankulp.com/blog - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 dk...@apache.org http://www.dankulp.com/blog
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 5:20 PM, Matthieu Riou matth...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 4:05 PM, Leo Simons m...@leosimons.com wrote: On Wed, Nov 11, 2009 at 5:20 PM, Matthieu Riou matth...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Wed, Nov 11, 2009 at 9:21 AM, Emmanuel Lecharny elecha...@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)u8...@4vyy95R\F)R=6-E+G-N61ED\!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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 matth...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
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 gst...@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 matth...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Review-Then-Commit
On Thu, Nov 12, 2009 at 4:16 AM, Greg Stein gst...@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-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
