[TRADUCCIÓN]Cadena no traducida... difícil de encontrar
En los foros algunos voluntarios están reportando errores de traducción. Ya están casi todos corregidos salvo el siguiente: http://user.services.openoffice.org/es/forum/viewtopic.php?p=25682#p25682 Citando al amigo Salva «Al agrupar una tabla dinámica con un campo de columnas de tipo fecha por trimestres y años se muestra Years en lugar de Años» El problema es que no sé cómo buscar esa cadena... ¿Alguna idea? Saludos Ricardo -- Para cancelar: ooo-general-es-unsubscr...@incubator.apache.org Para más información: http://www.openoffice.org/es/
Datos de las descargas de AOO 3.4
Hola a todos, Interesantes las estadísticas de las descargas de Apache OpenOffice 3.4 (que casi llegan a los 2 millones) http://s.apache.org/8bU Cantidades de descargas en español: Spain,66036 Mexico,18529 Argentina,15254 Colombia,7893 Chile,7667 Venezuela,4093 Peru,3341 Uruguay,2910 Ecuador,1739 Costa Rica,1385 Saludos -- Ariel Constenla-Haile La Plata, Argentina pgpyBxApNmp7i.pgp Description: PGP signature
Re: JIRA and communities
So, what message here should the incubator send a podling, or the foundation send a TLP? I really don't mean this as a rhetorical question at all, I'm honestly puzzled. In the case of Lucene, I've been hanging out for months, and I feel perfectly confident that it's a healthy community by any foundation standard. At the same time, you all are perfectly correct: watching them means dealing with a tsunami of trivia. I'm stumped at what suggestion, let alone demand, I'd deliver to such a community. - 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 12:29 PM, Ralph Goers ralph.go...@dslextreme.comwrote: 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. What purpose will these recommendations serve? * We have established that there is sufficient diversity in the committers list. * Without counting you, there are two other non-Cloudera PPMC who have expressed their commitment to the project. * The VOTE thread has overwhelmingly established what the community wants. * We, the active PPMC have demonstrated self-governance using accepted Apache practices and are committed to growing and diversifying the project further. If at this stage you insist on postponing the graduation, I am inclined to think that perhaps your own preferences outweigh that of the project and community. Please don't get me wrong - I am not accusing you of anything, just requesting you to please consider revoking your -1 vote. Arvind Prabhakar Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Crunch into the Apache Incubator
On 23 May 2012 19:45, Josh Wills jwi...@cloudera.com wrote: I would like to call a vote for accepting Apache Crunch for incubation in the Apache Incubator. The full proposal is available below. We ask the Incubator PMC to sponsor it, with phunt as Champion, and phunt, tomwhite, and acmurthy volunteering to be Mentors. Please cast your vote: [ ] +1, bring Crunch into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring Crunch into Incubator, because... -0, binding. I think it's good to broaden the Hadoop stack beyond Java, which is what Crunch proposes. I know it has a limited organisational breadth -but that is one thing incubation is designed to address. I just fear that the exclusion of Jakob putting things off to a bad start.
Re: [DISCUSS] Crunch to join the Apache Incubator
On 25 May 2012 20:00, Josh Wills jwi...@cloudera.com wrote: Hi Steve, Thank you for your thoughtful comments. Replies inlined below. 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. :) It's still a fairly limited set of organisations and lacks independence. Jakob and colleagues have no strategic goals in ensuring the success/failure of any specific OSS project, merely getting the right tools for their job. In a true OSS project -not one that is released under some OSS license but is effectively a single-vendor-project (JBoss, MySQL, etc) - end users are not merely consumers of the output, they are potential engineering resources to be co-opted, be it in their suggestions for improvement, documentation, bugreps, tests and code itself. That's the challenge -and it's not easy, especially in a project where some of the developers work on it full time, others are people that use it a bit and find bugs. Those little contributors need to be nurtured until they become good ones. 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. Not Apache politics, but a core belief: the notion that a community is actually more important than the codebase itself. The goal of an incubating project is not so much to get into the code into a shape where it is ready to graduate -but build a community to a point where it is considered successful. If you don't want that, but instead want to have a project over which you retain tight control, you are free to continue to host it on github. 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. That is good, and their past and hopefully ongoing work will help the project -I just think that it would have helped the project if Jakob's had been embraced 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. I all I have are concerns that the proposal is at risk from the same problems that others have had in incubation. 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. It's not clear that Flume has widened its developer base significantly enough for it to graduate. I fear that Crunch is exposed to the same risks, and the fact that you are opting to exclude Jakob from the initial dev team concerns me. -Steve
JIRA scalability issues
On Fri, May 25, 2012 at 12:57 AM, Steve Loughran steve.lough...@gmail.com wrote: It is becoming a bit of a SPOF, isn't it? What has changed about our JIRA instance is both its size and its increasing integration into the workflows of some projects. It always was a SPOF, but now we are feeling it more because it is getting harder to keep online, harder to troubleshoot, and more sorely missed when it is unavailable. Unfortunately, JIRA is not a distributed application. There is one massive database. There is one process. Resource utilization exceeding the capabilities of a single machine isn't a problem yet. Traffic isn't too heavy -- 3-4 hits a second on average, from what I hear. But when you have to reindex, it takes hours, and when you have to restart, it takes several minutes. That sluggishness severely impedes troubleshooting -- a problem that could be isolated in minutes with a smaller JIRA instance and near-instantaneous restarts takes hours to solve with a database as big as ours. The JIRA project import pains which have affected the Flex podling are related to this. JIRA is a pain to upgrade because it is big and finicky about JREs and operating systems, and because our infamous custom checkbox module makes things tricky. There was some question about whether version discrepancies were aggravating the Flex import failures, but nobody wanted to go through the upgrade to see if that helped. Then, JIRA security vulnerabilities forced Infra's hand this week. The consequence was a lot of downtime and a lot of frustration and stress for everybody while Infra has worked through the upgrade with lots of 5-minute restart cycles. It has been at least as painful as everyone had anticipated. This list isn't the venue for solving these problems, but as JIRA scalability issues are impacting podlings and projects, I think it's wise for us to take the situation into account. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
On Sat, May 26, 2012 at 7:51 AM, Benson Margulies bimargul...@gmail.com wrote: So, what message here should the incubator send a podling, or the foundation send a TLP? I really don't mean this as a rhetorical question at all, I'm honestly puzzled. There are a couple of technical mitigations which can help, such as disabling the ability to edit comments. I made another suggestion on the Infra list this morning regarding trimming context from JIRA notifications[1], but it turned out to be impractical given the strain of supporting JIRA already. I think the core issue is the tension between accessibility and the advantages of heavily customized workflow. Additionally, some people prefer to have conversations via web bulletin boards rather than email. That's hardly a new phenomenon. JIRA presents challenges because its email integration is awkward. It doesn't support replies, it uses a wiki markup language which doesn't translate well to plain text (compared to say, Markdown), it encourages really long lines, email content customization is not a first-class feature, and so on. The email integration of our JIRA workflows can be improved, but only to a certain extent. Perhaps one answer might be to create a competing system for patch contribution by integrating more closely with GitHub. I've done a little work building on what Jukka put in place for pull request notifications, and the GitHub API looks pretty flexible. If we make it easy to contribute patches via GitHub pull requests, and start capturing pull request comments to dev lists, then perhaps we'll have fewer conversations in JIRA. And unlike JIRA, we're not stuck with the limitations of a monolithic architecture -- our consumption of GitHub events happens via individual scripts. In the case of Lucene, I've been hanging out for months, and I feel perfectly confident that it's a healthy community by any foundation standard. At the same time, you all are perfectly correct: watching them means dealing with a tsunami of trivia. I'm stumped at what suggestion, let alone demand, I'd deliver to such a community. Lucene is at a different point in the product life cycle than most incoming podlings. Even if Lucene loses a few recruits, there are still plenty lining up to contribute -- thus there are fewer visible consequences if the project is not as inviting as it could be. I still think it would be worthwhile to pursue improvements for our JIRA based projects, though. For my own selfish reasons, I'd really like to follow Lucene dev discussions more closely, or be able to scan over Avro's dev list archives and figure out what on earth is going on. Marvin Humphrey [1] I suggested removing the nearly worthless inline summary context information which is repeated in every JIRA notification email. Sadly, this cannot be achieved using a plugin, and thus would make upgrading JIRA even more painful. Private archive of the thread here: http://s.apache.org/oJ [Any ASF committer can subscribe to infrastructure@a.o, but the archives are only accessible to full ASF Members, unfortunately.] - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JIRA and communities
Marvin, I am at your disposal to collaborate on something here; note my reply at infrastructure@. It seems to me that this thread would largely go better over there, now that the caveat that 'a podling run entirely on JIRA may have community problems' has been delivered. --benson - 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, On Fri, May 25, 2012 at 11:39 AM, Steve Loughran steve.lough...@gmail.com wrote: I'd go for pulling Jakob in for tactical and strategic reasons We grant committership based on merit, not tactics or strategy. Sounds to me like Josh and the rest of the team would be quite willing to add Jakob as soon as he shows up with a few patches or other contributions. Personally I've never fully understood the practice of allowing just about anyone to sign up as an initial committer of a podling. Putting your name on a list does not make you a part of a community, participating and contributing does. Recognizing such merit with committership is an important part of the social glue that binds our communities together. Of course it's a problem if it turns out that Jakob or anyone else ends up having trouble earning Crunch committership with reasonable effort, but so far I see little reason to worry about that. BR, Jukka Zitting - 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
I'll see Jukka one and raise him one. I have advised potential podlings to be very conservative with their initial list, and keep some potential contributors in their collective back pocket. This gives them a ready-made source of community growth, which is typically the scarcest and most precious commodity to a podling. Given the particular remarks around this case, as Jukka points out, it's a great, ahem, opportunity for founders to demonstrate their understanding of the preeminent value of community growth as opposed to code perfection. - 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
+1 Sent from my iPad On May 27, 2012, at 6:51 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Personally I've never fully understood the practice of allowing just about anyone to sign up as an initial committer of a podling. Putting your name on a list does not make you a part of a community, participating and contributing does. Recognizing such merit with committership is an important part of the social glue that binds our communities together. - 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
This isn't about whether or not they will respond appropriately to new
contributors once they are incubator project. And it's absolutely not
whether or not I should be an initial committer (the vote's going on
already and I'm happy it is).
Since the team has already stumbled in its first steps, I can't
imagine it would fail further. I'm sure the whole of the team will
step up (as part of the community). And I can't say if I'll
contribute or not. I'm perfectly fine with not being on the initial
team and believe the vote should finish and the proposal be accepted
(I'll put in a binding +1 shortly).
Instead, it's about the Podling's first steps to building a community,
which were:
1) Announcing the would follow the (in my view flawed) approach of S4
and reject any established members of the Apache community that may
wish to join during the proposal.
2) Announce an exception because one volunteer (Vinod) had a
particular background that would be useful.
3) Refuse a volunteer with a similar background but who has history of
being a critic of the company where the code originated.
4) When pressed to explain this irregularity, dig itself deeper by
inventing new concepts out of thin air ('de facto diversity', 'de jure
diversity') and seeming to suggest that membership on the initial dev
team was supposed to be some type of first-among equals status that
was a gift from one person:
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.
This would be a noble sentiment if Apache Martyr were a role and if it
didn't severely hobble the appearance of an honest effort at the
Apache meritocratic approach. As I said before, it takes a lot of
dedication to argue this passionately on a subject one professes
ignorance of.
After this, I think the possibility of such an attitude continuing
into the polling stage is quite small. After stumbling like this I'm
sure the team will make every effort to build the community as quickly
as possible.
On Sat, May 26, 2012 at 3:02 PM, Benson Margulies bimargul...@gmail.com wrote:
I'll see Jukka one and raise him one. I have advised potential
podlings to be very conservative with their initial list, and keep
some potential contributors in their collective back pocket. This
gives them a ready-made source of community growth, which is typically
the scarcest and most precious commodity to a podling. Given the
particular remarks around this case, as Jukka points out, it's a
great, ahem, opportunity for founders to demonstrate their
understanding of the preeminent value of community growth as opposed
to code perfection.
-
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: [VOTE] Accept Crunch into the Apache Incubator
+1. Josh and his cohorts have gotten a quick, unexpected introduction to the value of building a diverse community. But the code's solid and the lessons learned. Looking forward to this one. On Sat, May 26, 2012 at 7:16 AM, Steve Loughran steve.lough...@gmail.com wrote: On 23 May 2012 19:45, Josh Wills jwi...@cloudera.com wrote: I would like to call a vote for accepting Apache Crunch for incubation in the Apache Incubator. The full proposal is available below. We ask the Incubator PMC to sponsor it, with phunt as Champion, and phunt, tomwhite, and acmurthy volunteering to be Mentors. Please cast your vote: [ ] +1, bring Crunch into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring Crunch into Incubator, because... -0, binding. I think it's good to broaden the Hadoop stack beyond Java, which is what Crunch proposes. I know it has a limited organisational breadth -but that is one thing incubation is designed to address. I just fear that the exclusion of Jakob putting things off to a bad start. - 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
Inlined.
On Sat, May 26, 2012 at 3:20 PM, Jakob Homan jgho...@gmail.com wrote:
This isn't about whether or not they will respond appropriately to new
contributors once they are incubator project. And it's absolutely not
whether or not I should be an initial committer (the vote's going on
already and I'm happy it is).
Since the team has already stumbled in its first steps, I can't
imagine it would fail further. I'm sure the whole of the team will
step up (as part of the community). And I can't say if I'll
contribute or not. I'm perfectly fine with not being on the initial
team and believe the vote should finish and the proposal be accepted
(I'll put in a binding +1 shortly).
It has certainly been a...let's go with brisk, education. :)
Jakob, for whatever it is worth, we would be thrilled to have you, and
Joseph, and anyone else at LinkedIn who is interested join Crunch as
committers. Whatever the Apache Incubator equivalent of rolling out
the red carpet is, that's what we'll do.
Instead, it's about the Podling's first steps to building a community,
which were:
1) Announcing the would follow the (in my view flawed) approach of S4
and reject any established members of the Apache community that may
wish to join during the proposal.
2) Announce an exception because one volunteer (Vinod) had a
particular background that would be useful.
3) Refuse a volunteer with a similar background but who has history of
being a critic of the company where the code originated.
4) When pressed to explain this irregularity, dig itself deeper by
inventing new concepts out of thin air ('de facto diversity', 'de jure
diversity') and seeming to suggest that membership on the initial dev
team was supposed to be some type of first-among equals status that
was a gift from one person:
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.
This would be a noble sentiment if Apache Martyr were a role and if it
didn't severely hobble the appearance of an honest effort at the
Apache meritocratic approach. As I said before, it takes a lot of
dedication to argue this passionately on a subject one professes
ignorance of.
Okay, that last line was pretty funny.
After this, I think the possibility of such an attitude continuing
into the polling stage is quite small. After stumbling like this I'm
sure the team will make every effort to build the community as quickly
as possible.
Indeed we will. And to Benson's point, there are several people, none
of whom work at the organizations involved in the initial proposal,
who have made contributions to Crunch and that we would like to
continue to work with and have them grow to become committers on the
project. Expanding and diversifying the community based on merit is
our singular focus.
On Sat, May 26, 2012 at 3:02 PM, Benson Margulies bimargul...@gmail.com
wrote:
I'll see Jukka one and raise him one. I have advised potential
podlings to be very conservative with their initial list, and keep
some potential contributors in their collective back pocket. This
gives them a ready-made source of community growth, which is typically
the scarcest and most precious commodity to a podling. Given the
particular remarks around this case, as Jukka points out, it's a
great, ahem, opportunity for founders to demonstrate their
understanding of the preeminent value of community growth as opposed
to code perfection.
-
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
--
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)
Hi, On Sat, May 26, 2012 at 7:11 PM, Arvind Prabhakar arv...@apache.org wrote: * We have established that there is sufficient diversity in the committers list. I tend to look more at actual commit activity than the committers list when evaluating the diversity of a project. There are people on the Flume committers list who've never committed anything. Combining information from svn statistics [1] and committer affiliations [2] I get the following list of Flume commit activity so far this year: arvind - 116 commits - Cloudera prasadm - 22 commits - Cloudera brock - 16 commits - Cloudera esammer - 4 commits - Cloudera jarcec - 1 commit - AVG Technologies juhanic - 1 commit - CyberAgent The only two non-Cloudera commits were pretty trivial changes (a plugin version upgrade [3] and a spelling fix [4]). My earlier classification of Flume as ready to graduate [5] was partially based on these new committers from outside Cloudera, but the above data suggests that they haven't been as active as I would have hoped. IIUC Flume operates under an RTC model where people are not supposed to commit their own changes, which obviously makes the above data less relevant for evaluating the true diversity of the community. However, seeing only a single trivial commit by both jarcec and juhanic even though they became committers already over three months ago does seem to suggest that they may not be as comfortable in their committer role as people from Cloudera are. Do you think this is a problem for the community? If yes, how do you plan to fix it? If not, why? [1] http://svnsearch.org/svnsearch/repos/ASF/search?from=20120101to=20121231path=%2Fincubator%2Fflume [2] http://incubator.apache.org/flume/team-list.html [3] http://svn.apache.org/viewvc?view=revisionrevision=1305478 [4] http://svn.apache.org/viewvc?view=revisionrevision=1342066 [5] http://markmail.org/message/kq5ixay6z3erw3pc BR, Jukka Zitting - 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 26, 2012, at 10:11 AM, Arvind Prabhakar wrote: On Fri, May 25, 2012 at 12:29 PM, Ralph Goers ralph.go...@dslextreme.comwrote: 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. What purpose will these recommendations serve? * We have established that there is sufficient diversity in the committers list. * Without counting you, there are two other non-Cloudera PPMC who have expressed their commitment to the project. * The VOTE thread has overwhelmingly established what the community wants. * We, the active PPMC have demonstrated self-governance using accepted Apache practices and are committed to growing and diversifying the project further. If at this stage you insist on postponing the graduation, I am inclined to think that perhaps your own preferences outweigh that of the project and community. Please don't get me wrong - I am not accusing you of anything, just requesting you to please consider revoking your -1 vote. Arvind - my preferences are my following through as a mentor for Flume and insuring the project's success. That is my duty as a member of the ASF and the obligation I took on as a member of the IPMC. One measure of that would be to consider what would happen if all the Cloudera people were to suddenly vanish from the project (this could easily happen if Cloudera were purchased by a larger company who had different goals). As it stands today I don't believe the project would survive very long. Ralph - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[RESULTS] [VOTE] Accept Crunch into the Apache Incubator
The vote passes with twelve +1s from Incubator PMC members: Arun Murthy Alan Cabrera Benson Margulies Bertrand Delacretaz Doug Cutting Luciano Resende Jukka Zitting Matthew Franklin Niall Pemberton Patrick Hunt Tom White Tommaso Teofili seven non-binding +1s, and one 0- from Incubator PMC member Steve Loughran. Thank you everyone for voicing both your support and your concerns. The discussion around the proposal was enlightening and useful, and will hopefully benefit other projects that are considering the Apache incubator. Josh On Sat, May 26, 2012 at 3:31 PM, Jakob Homan jgho...@gmail.com wrote: +1. Josh and his cohorts have gotten a quick, unexpected introduction to the value of building a diverse community. But the code's solid and the lessons learned. Looking forward to this one. On Sat, May 26, 2012 at 7:16 AM, Steve Loughran steve.lough...@gmail.com wrote: On 23 May 2012 19:45, Josh Wills jwi...@cloudera.com wrote: I would like to call a vote for accepting Apache Crunch for incubation in the Apache Incubator. The full proposal is available below. We ask the Incubator PMC to sponsor it, with phunt as Champion, and phunt, tomwhite, and acmurthy volunteering to be Mentors. Please cast your vote: [ ] +1, bring Crunch into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring Crunch into Incubator, because... -0, binding. I think it's good to broaden the Hadoop stack beyond Java, which is what Crunch proposes. I know it has a limited organisational breadth -but that is one thing incubation is designed to address. I just fear that the exclusion of Jakob putting things off to a bad start. - 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)
Hi Jukka, On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote: Hi, On Sat, May 26, 2012 at 7:11 PM, Arvind Prabhakar arv...@apache.org wrote: * We have established that there is sufficient diversity in the committers list. I tend to look more at actual commit activity than the committers list when evaluating the diversity of a project. There are people on the Flume committers list who've never committed anything. Combining information from svn statistics [1] and committer affiliations [2] I get the following list of Flume commit activity so far this year: arvind - 116 commits - Cloudera prasadm - 22 commits - Cloudera brock - 16 commits - Cloudera esammer - 4 commits - Cloudera jarcec - 1 commit - AVG Technologies juhanic - 1 commit - CyberAgent The only two non-Cloudera commits were pretty trivial changes (a plugin version upgrade [3] and a spelling fix [4]). My earlier classification of Flume as ready to graduate [5] was partially based on these new committers from outside Cloudera, but the above data suggests that they haven't been as active as I would have hoped. IIUC Flume operates under an RTC model where people are not supposed to commit their own changes, which obviously makes the above data less relevant for evaluating the true diversity of the community. However, seeing only a single trivial commit by both jarcec and juhanic even though they became committers already over three months ago does seem to suggest that they may not be as comfortable in their committer role as people from Cloudera are. As you noted in your comments above - the Flume project tends to follow RTC with the reviewer committing the code. I happen to have taken up the role of the reviewer for the most part and hence you see the skewed commit counts. If you want to see the actual contribution, I would suggest looking at fixed JIRA issues by assignees. A quick report yields the following: aprabhkar - 26 - Cloudera [6] brocknoland - 19 - Cloudera [7] esammer - 56 - Cloudera [8] hshreedharan - 34 - Cloudera [9] jarcec - 6 - AVG Technologies [10] jmhsieh - 8 - Cloudera [11] juhanic - 9 - CyberAgent [12] mpercy - 34 - Cloudera [13] m...@apache.org - 1 - Trend Micro [14] prasadm - 34 - Cloudera [15] t...@cloudera.com - 3 - Cloudera [16] w...@cloudera.com - 3 - Cloudera [17] Looking at this, the average number of issues resolved by Cloudera committers (not counting Tom who is a mentor) is 26, and that for non-Cloudera committers is 5. Note that this number does not include other committer work such as the number of code reviews they have done, the number of design discussions they have participated in, something that is very valuable to the project. Do you think this is a problem for the community? If yes, how do you plan to fix it? If not, why? I don't think this is a problem because while most Cloudera committers have the luxury of working on the project during regular working hours, others do that during their off hours. Hence the majority of contributions coming from Cloudera. If all committers were to be non-Cloudera, I am sure the averages will be low and comparable to what the non-Cloudera contribution rate is at the moment. In other words, the project growth will definitely slow down, but the community will remain healthy. This is also indicated by the following statistics: User List: Messages in May: 171, April: 119 Number of Subscribers: 102 Dev List: Messages in May: 642, April 1024 Number of Subscribers: 245 [6] http://s.apache.org/2hi [7] http://s.apache.org/kw [8] http://s.apache.org/nl [9] http://s.apache.org/SGe [10] http://s.apache.org/tR [11] http://s.apache.org/UvH [12] http://s.apache.org/A8V [13] http://s.apache.org/f8M [14] http://s.apache.org/TIK [15] http://s.apache.org/wO [16] http://s.apache.org/Fxb [17] http://s.apache.org/rw Thanks, Arvind Prabhakar [1] http://svnsearch.org/svnsearch/repos/ASF/search?from=20120101to=20121231path=%2Fincubator%2Fflume [2] http://incubator.apache.org/flume/team-list.html [3] http://svn.apache.org/viewvc?view=revisionrevision=1305478 [4] http://svn.apache.org/viewvc?view=revisionrevision=1342066 [5] http://markmail.org/message/kq5ixay6z3erw3pc BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Open enrollment
On Sat, May 26, 2012 at 3:02 PM, Benson Margulies bimargul...@gmail.com wrote: I'll see Jukka one and raise him one. I have advised potential podlings to be very conservative with their initial list, and keep some potential contributors in their collective back pocket. This gives them a ready-made source of community growth, which is typically the scarcest and most precious commodity to a podling. +1 I'm less seasoned than others here who have done a lot of Mentoring, but my impression is that the act of identifying, nominating and voting in a new committer or PPMC member is a valuable experience for a fledgling community in and of itself -- going through the process seems to be beneficial, not just in terms of securing a new recruit and boosting their morale, but for those doing the recruiting as they debate and become comfortable with granting privileges to new contributors. Adding full PPMC members during the informal open enrollment period prior to the VOTE on entering incubation limits the number of times a PPMC gets to go through this invigorating experience. Perhaps that implies that the Incubator should actively discourage open enrollment! On the other hand, open enrollment can be a useful recruiting tool. It was absolutely vital for AOO (whose circumstances were unique) but it has been valuable for other projects as well -- you don't want to squander any of the initial excitement and publicity a new proposal generates. I believe there may be a best-of-both-worlds solution: * Incubation proposals should have separate sections for Initial Committers and Initial PPMC Members. * There should be text in the proposal encouraging people to add themselves to the list of Initial Committers and to introduce themselves on general@incubator -- but no such text regarding the list of Initial PPMC members. The open enrollment period has historically been controversial -- Crunch is not the first project to wrestle with it. Under this proposal, we avoid rushing not-yet-podlings into granting strangers who have not yet demonstrated merit a governance stake, but ease them into the essential Apache process of expanding and refreshing their community as soon as the possible. Signing on as a committer affords anyone who joins during open enrollment the convenience of CTR (for projects that use that process), which ought to provide sufficient incentive to keep people joining up -- yet it also gives the podling the opportunity to vote people into the PPMC early and often. And if committers who demonstrate merit are *not* brought into the PPMC, the podling's Mentors and the IPMC should take notice. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
