Re: Flume Graduation (was Re: June reports in two weeks)
Hi, On Thu, May 24, 2012 at 12:06 PM, Dave Fisher dave2w...@comcast.net wrote: I started reading some of the Flume website and I think that when you go to the main Wiki page: https://cwiki.apache.org/confluence/display/FLUME/Index When you click on the Flume Cookbook the resource is at cloudera.org. http://archive.cloudera.com/cdh/3/flume/Cookbook/ This page lists flume-...@cloudera.org and is a file with a revision dated May 7, 2012. Thanks. These have been removed. You can make you own conclusions, but it looks like podling resources need to be migrated to the ASF. These were kept to facilitate the transitoin over to Flume 0.9.5 which never happened. We instead went straight to 1.0.0. Other than that all resources have been migrated. Thanks, Arvind Prabhakar Regards, Dave In any case - I'm not insisting that the way the project is run needs to change. I'm simply saying I cannot support graduation with the current makeup of the committers and PMC. I don't have a hard and fast ratio - gaining 10 new unaffiliated committers who don't do much isn't nearly as good as 2 or 3 who are very active. Ultimately the project needs to figure out how to solve this. Stating that some committers who don't do much isn't nearly as good as 2 or 3 who are very active is an unfair characterization. This is more unfair for those who are part of the project but have not been active lately due to whatever reasons, but have played a foundational role in getting the project to a point where it is today. I think they are as important as any other committer who may be very active at the moment. Merit once earned, never expires [1]. [1] http://www.apache.org/dev/committers.html#committer-set-term I think you misunderstood my point or I didn't state it very well. Diversity isn't achieved simply by having bodies. IOW I am not suggesting offering commit rights to people who haven't earned it just to meet some ratio. However, I am not suggesting the project has ever even considered doing that. Ralph - 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: Flume Graduation (was Re: June reports in two weeks)
On Thu, May 24, 2012 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 24, 2012, at 10:40 AM, Arvind Prabhakar wrote: There are four companies represented in this list: AVG Technologies, Cloudera, CyberAgent and Trend Micro. Compared to other projects that have successfully graduated from Incubator in the past, this meets the diversity requirements very well. I was mistaken and the list above is indeed correct. For some reason I thought a couple of them had become Cloudera employees. However, none of those three are currently on the PPMC. When you look at the PPMC list you should also include a few more Cloudera people who do participate in release votes and PPMC issues. Most, if not all, of the non-Cloudera PMC members don't. Back in October of 2011 the PPMC discussed and decided to use the process where new committers are not automatically added to PPMC. We have since followed this process and added one committer to the PPMC recently. The current PPMC consists of: * Andrew Bayer (Cloudera) * Ahmed Radwan (Cloudera) * Arvind Prabhakar(Cloudera) * Bruce Mitchener (Independent) * Derek Deeter (Intuit) * Eric Sammer (Cloudera) * Henry Robinson (Cloudera) * Jonathan Hsieh (Cloudera) * Aaron Kimball (Odiago) * Ralph Goers (Intuit) There is a representation of at least four companies in this list. This, plus the the fact that we have demonstrated our commitment to the policies that we set forth, give me the confidence that we are on the right track. Diversity is a priority and will continue to be post graduation. Arvind In any case - I'm not insisting that the way the project is run needs to change. I'm simply saying I cannot support graduation with the current makeup of the committers and PMC. I don't have a hard and fast ratio - gaining 10 new unaffiliated committers who don't do much isn't nearly as good as 2 or 3 who are very active. Ultimately the project needs to figure out how to solve this. Stating that some committers who don't do much isn't nearly as good as 2 or 3 who are very active is an unfair characterization. This is more unfair for those who are part of the project but have not been active lately due to whatever reasons, but have played a foundational role in getting the project to a point where it is today. I think they are as important as any other committer who may be very active at the moment. Merit once earned, never expires [1]. [1] http://www.apache.org/dev/committers.html#committer-set-term I think you misunderstood my point or I didn't state it very well. Diversity isn't achieved simply by having bodies. IOW I am not suggesting offering commit rights to people who haven't earned it just to meet some ratio. However, I am not suggesting the project has ever even considered doing that. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
On May 25, 2012, at 2:46 AM, Arvind Prabhakar wrote: On Thu, May 24, 2012 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 24, 2012, at 10:40 AM, Arvind Prabhakar wrote: There are four companies represented in this list: AVG Technologies, Cloudera, CyberAgent and Trend Micro. Compared to other projects that have successfully graduated from Incubator in the past, this meets the diversity requirements very well. I was mistaken and the list above is indeed correct. For some reason I thought a couple of them had become Cloudera employees. However, none of those three are currently on the PPMC. When you look at the PPMC list you should also include a few more Cloudera people who do participate in release votes and PPMC issues. Most, if not all, of the non-Cloudera PMC members don't. Back in October of 2011 the PPMC discussed and decided to use the process where new committers are not automatically added to PPMC. We have since followed this process and added one committer to the PPMC recently. The current PPMC consists of: * Andrew Bayer (Cloudera) * Ahmed Radwan (Cloudera) * Arvind Prabhakar(Cloudera) * Bruce Mitchener (Independent) * Derek Deeter (Intuit) * Eric Sammer (Cloudera) * Henry Robinson (Cloudera) * Jonathan Hsieh (Cloudera) * Aaron Kimball (Odiago) * Ralph Goers (Intuit) There is a representation of at least four companies in this list. This, plus the the fact that we have demonstrated our commitment to the policies that we set forth, give me the confidence that we are on the right track. Diversity is a priority and will continue to be post graduation. Are you really going to resort to distortion of the truth to try to claim diversity? I work with Derek and know that he has never participated in Flume since its inception. I also can't recall Bruce or Aaron participating after the podling started. All of them appear to have just signed the initial wiki page to get on the PPMC. I'm not sure why you left Tom White and Patrick Hunt off as they are both mentors and are PPMC members and both have participated in PMC discussions. That leaves just me as the only non-Cloudera PPMC member who actively participates and I don't commit code and I've been on the PPMC primarily as a mentor. If you somehow believe that this constitutes diversity than my job as a mentor has a long way to go. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
I was involved with Flume prior to coming to Apache ... then a baby arrived and things sort of changed for the last year. But you're right that I haven't been around since then ... I still have a couple of source trees around with various changes in them, but no idea what the status of any of that is. :/ - Bruce On Fri, May 25, 2012 at 10:03 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Are you really going to resort to distortion of the truth to try to claim diversity? I work with Derek and know that he has never participated in Flume since its inception. I also can't recall Bruce or Aaron participating after the podling started. All of them appear to have just signed the initial wiki page to get on the PPMC.
Re: [DISCUSS] Crunch to join the Apache Incubator
On 23 May 2012 19:35, Josh Wills jwi...@cloudera.com wrote: Hey Jakob, This was a tough one-- you know that I've been talking about Crunch w/Joe Adler for a few weeks now, and I personally am really looking forward to working with you guys. That said, the team did feel strongly about keeping the initial committers to people who had already added major pieces of functionality to Crunch, and adding Vinod was about his expertise on the MR2 internals, which we think will be critical to Crunch's success. We are going to put the Crunch proposal up for a vote with the current team in place. We are, of course, very eager to grow the list of committers through the normal Apache process. I'd go for pulling Jakob in for tactical and strategic reasons 1. He's using it at work, so represents the end users. 2. His code is always of high quality 3. Given the ongoing discussion on diversity w.r.t Flume, I think it would be wise to not follow that projects example, and try to get broader involvement from the outset. Irrespective of the committer list at entry, you will need that broader community at exit, so getting them in early is good. Anyway, your decision, it won't effect my voting -it's just a different action from that which I'd have taken. Now, why are my tests failing... Steve
Re: Flume Graduation (was Re: June reports in two weeks)
On 24 May 2012 07:44, Marvin Humphrey mar...@rectangular.com wrote: To me that seems like it raises a barrier to entry -- but then, there are numerous projects around the ASF who are not hurting for contributors and who use JIRA for *everything* -- starting with Hadoop and Lucene. I first encountered when I subbed to the Maven dist for a while. Very different from ant-dev, which was pure distributed community and axis-dev, which had some commercial team engagement (IBM), but in which WSO2 strive hard to not be exclusionary. -- Marvin Humphrey, who in moments of weakness fantasizes about the day when Infra can no longer keep the massive ASF JIRA instance from toppling over and all the Java projects whose participation in Infra is limited to complaining when stuff goes offline come crying. It is becoming a bit of a SPOF, isn't it?
Re: Flume Graduation (was Re: June reports in two weeks)
On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote: I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. I'm not convinced that JIRA helps communities. It's great in companies -IDE integration, you can bounce issues to others, it pings your phone so often you can use it as a network liveness test. It also lets you persist discussions in a way that can be searched. In a busy project, it helps you keep track of your workload, and can assist in sprint planning if you fill in the est/actual workload fields. But -it encourages people to watch the issues they care about, and ignore the rest -it pushes you towards discussion-on-jira rather than in the mailing list -those discussions tend to be focused, rather than generic community chitchat about dev issues. When you compare it to the community of the pure-email list groups, or the socialness of github, JIRA seems to me that it pushes you towards antisocialism, to sit in your office and care only about the 8 JIRAs you have marked as in progress. Given the ubiquity and value of JIRA, what can be done here?
JIRA and communities
On Fri, May 25, 2012 at 12:53 AM, Steve Loughran steve.lough...@gmail.com wrote: On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote: I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. I'm not convinced that JIRA helps communities. It's great in companies -IDE integration, you can bounce issues to others, it pings your phone so often you can use it as a network liveness test. It also lets you persist discussions in a way that can be searched. In a busy project, it helps you keep track of your workload, and can assist in sprint planning if you fill in the est/actual workload fields. I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. Meanwhile, some projects, with or without JIRA, just creep along making small, incremental, changes and bugfixes. There's no grand strategy or vision, and, as a result, not much to talk about most of the time. Bugs and requests come in and people deal with them -- or not. So, I won't claim that your disfunction scenario is impossible or never observed at the ASF. I will point out that bugzilla could be used just as effectively to create the same problem. As a mentor, what I care about is what happens when a new person shows up. Does the dev list manage to welcome and encourage that person? Or does that person find a mysterious, opaque situation in which there seems to be a secret code that has to be broken to get a contribution accepted? If welcome and encouragement amounts to 'go find a JIRA and get busy,' that does not bother me, so long it leads to the happy result of applied patches and eventual karma. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On May 25, 2012, at 8:37 AM, Benson Margulies wrote: On Fri, May 25, 2012 at 12:53 AM, Steve Loughran steve.lough...@gmail.com wrote: On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote: I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. I'm not convinced that JIRA helps communities. It's great in companies -IDE integration, you can bounce issues to others, it pings your phone so often you can use it as a network liveness test. It also lets you persist discussions in a way that can be searched. In a busy project, it helps you keep track of your workload, and can assist in sprint planning if you fill in the est/actual workload fields. I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. I have no problem with Jira, it is a great tool. My problem - specific to the way Flume does things - is that they also use the Review tool and you end up with a copy of a message from the Review tool and another copy of the same thing from Jira. A LOT of those messages are pure noise. The ones that do contain content do a poor job of quoting whatever is being commented on. So the only way to really tell what is going on is to go into Jira and look at every issue. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Crunch to join the Apache Incubator
Hi Jukka, Apologies for the delay, I had a vacation day. Replies inline. On Wed, May 23, 2012 at 2:33 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Wed, May 16, 2012 at 2:23 AM, Josh Wills jwi...@cloudera.com wrote: http://wiki.apache.org/incubator/CrunchProposal Some comments from the related vote thread: formally released twice, as versions 0.1.0 (October 2010) and 0.2.0 s/2010/2011/ I presume. Indeed. Fixed. == Source and Intellectual Property Submission Plan == * The initial source is already licensed under the Apache License, Version 2.0. https://github.com/cloudera/crunch/blob/master/LICENSE.txt A software grant is customary for existing codebases. Understood-- is there an example of the appropriate language? == Github Repositories == http://github.com/apache/crunch git://git.apache.org/crunch.git I assume you mean that you want to develop the codebase using Git instead of Subversion here at the ASF? See http://git-wip-us.apache.org/ for more info, and please get in touch with infra about the details. A volunteer to help manage the Git repository will be appreciated. Yes, git is our preference. I will get in touch with infra and volunteer to do the repo management. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Director of Data Science Cloudera Twitter: @josh_wills - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
On Fri, May 25, 2012 at 8:03 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 25, 2012, at 2:46 AM, Arvind Prabhakar wrote: On Thu, May 24, 2012 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 24, 2012, at 10:40 AM, Arvind Prabhakar wrote: The current PPMC consists of: * Andrew Bayer (Cloudera) * Ahmed Radwan (Cloudera) * Arvind Prabhakar(Cloudera) * Bruce Mitchener (Independent) * Derek Deeter (Intuit) * Eric Sammer (Cloudera) * Henry Robinson (Cloudera) * Jonathan Hsieh (Cloudera) * Aaron Kimball (Odiago) * Ralph Goers (Intuit) There is a representation of at least four companies in this list. This, plus the the fact that we have demonstrated our commitment to the policies that we set forth, give me the confidence that we are on the right track. Diversity is a priority and will continue to be post graduation. Are you really going to resort to distortion of the truth to try to claim diversity? I work with Derek and know that he has never participated in Flume since its inception. I also can't recall Bruce or Aaron participating after the podling started. All of them appear to have just signed the initial wiki page to get on the PPMC. It is unfortunate that you think this way. Bruce and Aaron have played a foundational role in Flume and they deserve to be seated on the PPMC unless they explicitly request to be removed. I welcome their contribution anytime and hope that they chose to remain on the project. I'm not sure why you left Tom White and Patrick Hunt off as they are both mentors and are PPMC members and both have participated in PMC discussions. Because I counted them as mentors and not PPMC. I am happy to include them if they want to be counted as PPMC. Pardon me if I should not have made this distinction. The one person who was left out inadvertently was Prasad who recently got elected to PPMC. That leaves just me as the only non-Cloudera PPMC member who actively participates and I don't commit code and I've been on the PPMC primarily as a mentor. If you somehow believe that this constitutes diversity than my job as a mentor has a long way to go. You were counted because three months ago you announced that you would like to stay with the project post graduation. I don't remember seeing any communication from you stating your change of mind. That said, I respect your choice either way. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On Fri, May 25, 2012 at 8:37 AM, Benson Margulies bimargul...@gmail.com wrote: I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I claim it does both. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. I'm *really* interested in ongoing Lucene development, but I can't take following the Lucene dev list via email any more. The signal-to-noise ratio is horrible. Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack updated LUCENE-1040 Joe Sixpack reassigned LUCENE-1040 Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:11 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:12 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:13 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:14 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:15 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:16 PM: Hans Wijnkuhler edited comment on LUCENE-1984 at 11/11/11 11:17 PM: V. de Gin created LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 V. de Gin updated LUCENE-5150 Joe Sixpack reassigned LUCENE-5150 Joe Sixpack updated LUCENE-5150 It's a daily tsunami of trivia, redundant quotes, bloated diffs and butchered titles. (And then there are the dozens of Jenkins failure notifications, but I've figured out how to filter those.) For what it's worth, I recently considered exploring Apache Avro (the C implementation interests me), but the Avro dev list is similarly impenetrable and I gave up. Maybe I'll try again later... JIRA has its strengths, but its integration into mailing-list style development leaves much to be desired. So, I won't claim that your disfunction scenario is impossible or never observed at the ASF. I will point out that bugzilla could be used just as effectively to create the same problem. Sure. In a similar vein, there has been discussion about tighter integration with Github. We've been sending GitHub pull request notifications to ASF dev lists for a while now, and there's talk of mirroring pull request comments as well. If we handle the integration of Github comments as poorly as JIRA notifications, the potential exists to force new users to to learn Github's API in order to participate fully. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Crunch to join the Apache Incubator
Assuming the VOTE passes, I hope you'll still give the project a chance, Jakob. Given your rep around the ASF, if you contribute as you have to other projects yet your merit goes unrecognized, I suspect that the Crunch's Mentors are going to be asking questions. ;) I imagine we'll continue to evaluate and extend Crunch, whether as part of Incubator or not. I'm hopeful Crunch's incubation will turn out well and am confident Josh will make sure it does. After all, being willing to declare that rejecting offers of help from experienced volunteers during the incubator proposal is not the normal Apache process after having contributed 10 patches definitely shows a willingness to do whatever it takes to build the community the team wants in place. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On May 25, 2012, at 10:32 AM, Ralph Goers wrote: On May 25, 2012, at 8:37 AM, Benson Margulies wrote: On Fri, May 25, 2012 at 12:53 AM, Steve Loughran steve.lough...@gmail.com wrote: On 24 May 2012 06:15, Benson Margulies bimargul...@gmail.com wrote: I've met other groups of people who like a JIRA centric view of the world. I suspect that if they did a bunch of other good things called out below, you or others would find the JIRA business digestible. Also, on the other hand, I fear that the co-employed contributors are collaborating in the hallway, and the lack of the context in JIRA or on the list is contributing to the problem. I'm not convinced that JIRA helps communities. It's great in companies -IDE integration, you can bounce issues to others, it pings your phone so often you can use it as a network liveness test. It also lets you persist discussions in a way that can be searched. In a busy project, it helps you keep track of your workload, and can assist in sprint planning if you fill in the est/actual workload fields. I don't claim that JIRA helps, but I also don't accept the proposition that JIRA hurts. I think that we should focus on the community, not the tools. The JIRA-oriented projects I follow have JIRA set to send all new issues, and all new comments, to the dev list. So all community members, and, in particular, all PMC members with a duty to supervise, see all the traffic. I have no problem with Jira, it is a great tool. My problem - specific to the way Flume does things - is that they also use the Review tool and you end up with a copy of a message from the Review tool and another copy of the same thing from Jira. A LOT of those messages are pure noise. The ones that do contain content do a poor job of quoting whatever is being commented on. So the only way to really tell what is going on is to go into Jira and look at every issue. In my quick review yesterday in the ML, it really was difficult. The combination between Review and JIRA is worse than getting non-html COnfluence notifications which don't diff. You cannot know what is going on without the other tools. Bugzilla and JIRA notifications by themselves aren't too bad, at least these are incremental. It really is hard not to think that all the work is being done in JIRA and ReviewBoard and not on the ML. This makes oversight difficult. Regards, Dave Ralph - 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: [DISCUSS] Crunch to join the Apache Incubator
Hi Steve, Thank you for your thoughtful comments. Replies inlined below. On Fri, May 25, 2012 at 2:39 AM, Steve Loughran steve.lough...@gmail.com wrote: On 23 May 2012 19:35, Josh Wills jwi...@cloudera.com wrote: Hey Jakob, This was a tough one-- you know that I've been talking about Crunch w/Joe Adler for a few weeks now, and I personally am really looking forward to working with you guys. That said, the team did feel strongly about keeping the initial committers to people who had already added major pieces of functionality to Crunch, and adding Vinod was about his expertise on the MR2 internals, which we think will be critical to Crunch's success. We are going to put the Crunch proposal up for a vote with the current team in place. We are, of course, very eager to grow the list of committers through the normal Apache process. I'd go for pulling Jakob in for tactical and strategic reasons 1. He's using it at work, so represents the end users. A super-majority of the initial committers are also end users. I use Crunch on my own projects (e.g., http://github.com/cloudera/seismichadoop and http://github.com/cloudera/matching ), Cloudera solutions architects use Crunch on client projects, Robert is building tools on top of Crunch at WibiData, and Gabriel and Chris use it for building pipelines at TomTom. I can't speak for Tom and Vinod, but of course, they have other positive qualities. :) 2. His code is always of high quality I in no way meant to disparage Jakob or his coding. The objective of my reply was say no in the most apologetic, obsequious way possible while not going so far over the top as to sound insincere. Having LinkedIn on board would be a tremendous PR boost for the project. It was painful to say no. I am in no way savvy in the ways of Apache or the politics of the ASF. I understand that smart people who I respect a great deal think that this is the wrong decision. But I think that it takes something really great for someone to see a project like Crunch, play around with, and then take the time to make some contributions to it without any expectation of recognition, in the form of an Apache committership or anything else. That was what Gabriel and Chris and Robert did over the past few months. I really admire that, and I think that it deserves some special recognition, however small. I'm willing to have some people not like me or think I'm dumb if that's the price of giving that to them. 3. Given the ongoing discussion on diversity w.r.t Flume, I think it would be wise to not follow that projects example, and try to get broader involvement from the outset. I agree that it is critical to have broad involvement at the outset. Both S4 and Flume started out with at least 50% of their initial committers from a single company, and no single company constitutes a majority of the initial committers to Crunch (Cloudera has three, TomTom has two, WibiData has one, and Hortonworks has one). That de jure diversity mirrors the de facto diversity in Crunch's commit logs over the past several months: https://github.com/cloudera/crunch/commits/master There is nothing more important than increasing that de facto diversity over time. I fully expect that my role during the incubator process is to be the best documenter, repository maintainer, and recruiter of new contributors that I can be. Best, Josh -- Director of Data Science Cloudera Twitter: @josh_wills - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
On May 25, 2012, at 11:03 AM, Arvind Prabhakar wrote: That leaves just me as the only non-Cloudera PPMC member who actively participates and I don't commit code and I've been on the PPMC primarily as a mentor. If you somehow believe that this constitutes diversity than my job as a mentor has a long way to go. You were counted because three months ago you announced that you would like to stay with the project post graduation. I don't remember seeing any communication from you stating your change of mind. That said, I respect your choice either way. Arvind, I don't take disagreements like this personally and I hope you don't either. I have every intention of staying with the project after graduation and hopefully, finding a way to commit code as there are a number of areas I believe I can contribute. At this point my recommendations are: 1. Since the PPMC voted to separate being a committer and being a PMC member I would wait a couple of months and then add the new non-Cloudera committers to the PPMC if it is warranted. 2. Of course, add any new committers who have earned it. 3. Send an email to the entire PPMC asking them to confirm that they want to remain on the PMC after graduation. 4. Based on that we will know what the making of the post-graduation PMC will look like. 5. Raise the topic of graduation as a discussion item either on the PMC or dev list after the above 4 are completed. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Flume Graduation (was Re: June reports in two weeks)
Hi folks, Just to throw my hat into the ring on this subject: I recognize that I have been inactive from a contribution standpoint since Flume's introduction into the ASF incubator, but still follow Flume on the mailing lists and in other community meetups. I've done a bunch of work with Flume in the past, and I remain very interested in where Flume is going. Flume's direction is something important to me; but I have seldom weighed in, as I often felt that others were resolving things in a manner that did not require my input. Unfortunately, my duties with my own startup have prevented me from taking a more direct role in the building of Flume for quite some time. I believe that there are ways in which it makes sense for WibiData to directly integrate with Flume in the future -- but time and resources are scarce at a startup, so this has not been something I've yet demonstrated externally in front of the incubator community. I look forward to a time in the future when my duties are rearranged once again, and I can devote more of my time back to hacking than I do now :) (The one constant at a startup, after all, is change.) Regards, - Aaron Kimball PS -- My affiliation should be updated to WibiData; we changed the company name from Odiago to WibiData recently. On Fri, May 25, 2012 at 12:29 PM, Ralph Goers ralph.go...@dslextreme.comwrote: On May 25, 2012, at 11:03 AM, Arvind Prabhakar wrote: That leaves just me as the only non-Cloudera PPMC member who actively participates and I don't commit code and I've been on the PPMC primarily as a mentor. If you somehow believe that this constitutes diversity than my job as a mentor has a long way to go. You were counted because three months ago you announced that you would like to stay with the project post graduation. I don't remember seeing any communication from you stating your change of mind. That said, I respect your choice either way. Arvind, I don't take disagreements like this personally and I hope you don't either. I have every intention of staying with the project after graduation and hopefully, finding a way to commit code as there are a number of areas I believe I can contribute. At this point my recommendations are: 1. Since the PPMC voted to separate being a committer and being a PMC member I would wait a couple of months and then add the new non-Cloudera committers to the PPMC if it is warranted. 2. Of course, add any new committers who have earned it. 3. Send an email to the entire PPMC asking them to confirm that they want to remain on the PMC after graduation. 4. Based on that we will know what the making of the post-graduation PMC will look like. 5. Raise the topic of graduation as a discussion item either on the PMC or dev list after the above 4 are completed. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[DISCUSS] Prototype ASF Mailing List Request form
https://whimsy.apache.org/infra/mlreq Nothing fancy: simple data gathering. Output will be validated and placed into svn as input to another tool down the chain. The topic I would like to discuss is what additional input validation should be done. Mailing list names have specific formats. Within the incubator, podling mailing list names are expected to have a specific format. But the mapping of podling names to mailing list names sometimes varies... Suggestions welcome. I'm starting with the incubator as it is the source for a bulk of the requests... - Sam Ruby - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
