Re: [VOTE] Accept Curator into the Incubator
[x] +1 (non binding) Eric On 05/03/2013 18:21, Jordan Zimmerman wrote: Discussion has settled down so I am calling a VOTE for acceptance of Curator into the Apache Incubator. The vote will close at on Friday, March 8, 2013. [ ] +1 Accept Curator into the Apache incubator [ ] +0 Don't care. [ ] -1 Don't accept Curator into the incubator because... Full proposal is pasted below and the corresponding wiki is http://wiki.apache.org/incubator/CuratorProposal Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Sincerely, Jordan Zimmerman === PROPOSAL === Curator - ZooKeeper client wrapper and rich ZooKeeper framework Abstract Curator is a set of Java libraries that make using Apache ZooKeeper much easier. While ZooKeeper comes bundled with a Java client, using the client is non-trivial and error prone. Proposal Curator is a set of Java libraries that make using Apache ZooKeeper much easier. While ZooKeeper comes bundled with a Java client, using the client is non-trivial and error prone. It consists of three components that build on each other. Curator Client is a replacement for the bundled ZooKeeper class that takes care of some low-level housekeeping and provides some useful utilities. Curator Framework is a high-level API that greatly simplifies using ZooKeeper. It adds many features that build on ZooKeeper and handles the complexity of managing connections to the ZooKeeper cluster and retrying operations. Curator Recipes consists of implementations of some of the common ZooKeeper recipes. Additionally, Curator Test is included which includes utilities to help with unit testing ZooKeeper-based applications. Background Curator was initially developed by Netflix to make writing ZooKeeper-based applications easier and more reliable. Curator was open-sourced by Netflix on GitHub as an Apache 2.0 licensed project in July 2011. During this time Curator has been formally released many times and has gained widespread adoption. Rationale New users of ZooKeeper are surprised to learn that a significant amount of connection management must be done manually. For example, when the ZooKeeper client connects to the ensemble it must negotiate a new session, etc. This takes some time. If you use a ZooKeeper client API before the connection process has completed, ZooKeeper will throw an exception. These types of exceptions are referred to as recoverable errors. Curator automatically handles connection management, greatly simplifying client code. Instead of directly using the ZooKeeper APIs you use Curator APIs that internally check for connection completion and wrap each ZooKeeper API in a retry loop. Curator uses a retry mechanism to handle recoverable errors and automatically retry operations. The method of retry is customizable. Curator comes bundled with several implementations (ExponentialBackoffRetry, etc.) or custom implementations can be written. The ZooKeeper documentation describes many possible uses for ZooKeeper calling each a recipe. While the distribution comes bundled with a few implementations of these recipes, most ZooKeeper users will need to manually implement one or more of the recipes. Implementing a ZooKeeper recipe is not trivial. Besides the connection handling issues, there are numerous edge cases that are not well documented that must be considered. For example, many recipes require that an ephemeral-sequential node be created. New users of ZooKeeper will not know that there is an edge case in ephemeral-sequential node creation that requires you to put a special marker in the node?s name so that you can search for the created node if an I/O failure occurs. This is but one of many edge cases that are not well documented but are handled by Curator. Current Status Meritocracy Curator was initially developed by Jordan Zimmerman in 2011 at Netflix. Developers external to Netflix provided feedback, suggested features and fixes and implemented extensions of Curator. Netflix's engineering team has since maintained the project and has been dedicated towards its improvement. Contributors to Curator include developers from multiple organizations around the world. Curator will be a meritocracy as it enters the Incubator and beyond. Community Curator is currently used by a number of organizations all over the world. Curator has an active and growing user and developer community with active participation in the http://groups.google.com/group/curator-users mailing list and at its GitHub home: https://github.com/Netflix/curator. Since open sourcing the project, there have been fifteen individuals from various organizations who have contributed code. Core Developers The core developers for Curator are: ? Jordan Zimmerman ? Jay Zarfoss Jordan has contributed towards Apache ZooKeeper and both Jordan
Re: [PROPOSAL] Curator for the Apache Incubator
Hi, Inputs from a current Curator user: I followed one year ago the public thread Patrick mentionned and was surprised to see the lack of interest for an higher level Zk client. If this discussion happened now, maybe the interest would be different, but still, I think Curator should be hosted in its own community for the following reasons: 1.- I would love to have a client that support multiple server types. I use for example Curator to take distributed locks on Zk servers, but other servers (Hazelcast...) also implement this functionality. Simply by configuration, I would love Curator to give me access to those servers without chaning my code. Ok, This is not in the proposal scope, but having a separate community opens to door to those type of contributions. Obviously, if Curator is part of Zookeeper, this will be more difficult. 2.- Zookeeper is getting more and more functionalities (Bookeeper, Hedwig...) but not all of these functionalities may find an client part in Curator. This is why (see my first point), Curator should not be stricly a full Zk client, but a client providing access in some way to some distributed server functions. 3.- Client dev (internal machinery such injection, configuration...) is quite different from server dev. Some client architecture decisions should not be depende on server dev habits and server developers tend to negligate clients. I feel everyday the pain of real hadoop/hbase/casssandra/... client (I mean without the server jars). This is evolving, but not having a separate project for client does not help. HTTP client have never been developer in server projects. I agree that hosting in the same community can create some convergence and ease the communication (API, bug solving...), but I still feel Curator deserves a dedicated community, especially for the first reason I have listed (client towards multiple servers). Thx, Eric On 26/02/2013 06:10, Patrick Hunt wrote: On Mon, Feb 25, 2013 at 7:10 PM, Greg Stein gst...@gmail.com wrote: My concern is that we're looking at two new committers, rather than a Curator community. Following normal Incubator work, Curator would build a community for itself. But then we'd have a community *distinct* from that of Zookeeper. And it really looks like this should be part of Zookeeper itself -- a more capable and easier-to-use client. So I question the incubation of this. Why do we want to build a new/separate project? Why isn't this just part of Zookeeper right from the start? I would suggest that this work is placed on a branch within Zookeeper. That Jordan and Jay become committers on that branch (not necessarily Zookeeper trunk). Over time, the branch can be folded into trunk, along with all the various tests, doc, and other artifacts that I see in the GitHub repository. And hopefully that Jordan and Jay become regular committers (and PMC members!) of the Zookeeper project itself. The current Zookeeper client can remain for backwards compat, and the Curator work can become the next-gen client. Honestly, in my opnion, incubating this project seems like it would create a distinct community, and really doesn't seem like it would serve the Zookeeper community. All that said, I am not familiar with the Zookeeper or Curator communities. But from this read, I don't think Incubation is the right approach. I would rather push for a more direct incorporation of Curator directly into Zookeeper. (use the short-form IP clearance) ... so, unless somebody can help me understand the communities and situation better, I'm -1 (binding) on this incubation. I'd rather see combined, rather than distinct, communities from the start. The Curator library is built upon the current ZooKeeper client libraries. They are an extension that implements higher level use cases (what we call recipes in ZK) whereas the ZK libraries implement lower level primitives. An analogy might be Apache Crunch (recently graduated to TLP) and MapReduce. Also, not everyone agrees with Jordan's assessment that Curator is 'better than (or a replacement for) the existing client libraries. The ZK community discussed incorporating the Curator code about a year ago. At that time there wasn't interest to adopt these libraries into ZK itself. My belief is that if Curator were to go through incubation the ZK community would be more likely to adopt it. Similar to how HCatalog spun off to work on the metastore and recently merged back into Hive. If there's significant overlap in the Curator podling community and the ZK community that will be a strong indication that they should be merged (my belief). If not it would have the opportunity to go TLP. Here's my report (ZooKeeper) to the board in Dec 2011 and the response I received. This is one of the reasons I advised Jordan to go the incubator approach. There's also the discussion thread on ZooKeeper dev if you want more insight. A discussion is currently
Re: [VOTE] Accept Onami proposal in the Incubator
in Apache Maven as Dependency Injection controller, hopefully the Maven community will be interested on extracting reusable some parts and contributing back to Onami project. Apache BeanUtils and and Apache Wink provide respectively a Google Guice integration module. Moreover, the Apache DeltaSpike community is developing a set of CDI extensions, which could find some synergies in our community. The Apache Logging Services project might have an special interest in the sli4j component, which allows Logger injections. == An Excessive Fascination with the Apache Brand == Even if the 99soft community recognizes the power and the attractiveness of the ASF brand, we are absolutely aware of our already established role in the wide Guice community. Furthermore, we are convinced that we can enthusiastically bring inside the ASF new and fresh energies in order to improve our visions, insights and knowledge about the other projects and, most important, to have the possibility of enlarge our small community with talented and passionate developers. = Documentation = 1. G-Guava[5] 2. Guartz[6] 3. GSPI[7] 4. JUnice[8] 5. Lifegycle[9] 6. Rocoto[10] 7. sli4j[11] 8. Gache[12] 9. Autobind[13] = Initial Source = The intial source comprises code developed on GitHub[14] licensed under The Apache Software License, Version 2.0 (contributed under Grant from Simone Tripodi for Onami). = Source and Intellectual Property Submission Plan = Source code will be moved from GitHub[14] space inside the SVN space of the podling. = External Dependencies = 99soft Guice extension depends to the following external dependencies: * Google Guice - released under The Apache Software License, Version 2.0 * Google Guava - released under The Apache Software License, Version 2.0 * javax.inject - released under The Apache Software License, Version 2.0 * javax.cache - released under the JPA license * AOP Alliance - released under the Public Domain * Quartz Scheduler - released under The Apache Software License, Version 2.0 * Commons Logging - released under The Apache Software License, Version 2.0 * Log4j - released under The Apache Software License, Version 2.0 * SLF4J - released under the MIT License == Test Dependencies == * JUnit - released under the Common Public License Version 1.0 * Easymock - released under The Apache Software License, Version 2.0 * Mockito - released under the MIT License = Cryptography = The project does not handle cryptography in any way. = Required Resources = * Mailing lists * onami-private (with moderated subscriptions) * onami-dev * onami-user * onami-commits * Subversion directory * https://svn.apache.org/repos/asf/incubator/onami * Website * Confluence (MAYHEM) * Issue Tracking * JIRA (MAYHEM) = Initial Committers = Names of initial committers - in alphabetical order - with current ASF status: * Christian Grobmeier grobmeier at apache dot org (Member) * Cody Ray cray at brighttag dot com (ICLA submitted) * Ghislain Picpoc Touratier ghislain dot touratier at gmail dot com (ICLA submitted) * Daniel Manzke daniel dot manzke at googlemail dot com (ICLA submitted) * Davide Palmisano dpalmisano at apache dot org (Committer) * Ioannis Canellos iocanel at apache dot org (Committer) * Jordi Gerona jordi at donky dot org (ICLA submitted) * Marco Speranza marcosperanza at apache dot org (Committer) * Marzia Forli marzia dot forli at yahoo.com (ICLA to be submitted) * Mohammad Nour El-Din mnour at apache dot org (Member) * Nino Martinez Wael nino dot martinez dot wael at gmail dot com (ICLA submitted) * Pawel Poltorak pawel dot poltorak at gmail.com (ICLA to be submitted) * Simone Tripodi simonetripodi at apache dot org (Member) * Stuart Mc``Culloch mcculls at apache dot org (Committer) * Thilo-Alexander Ginkel thilo at ginkel dot com (ICLA submitted) = Sponsors = == Champion == * Simone Tripodi simonetripodi at apache dot org == Nominated Mentors == * Christian Grobmeier grobmeier at apache dot org * Mohammad Nour El-Din mnour at apache dot org * Olivier Lamy olamy at apache dot org == Sponsoring Entity == * Incubator PMC = Other interested people (in alphabetical order) = * Eric Charles eric at apache dot org [ 1] http://code.google.com/p/google-guice/ [ 2] http://www.101zenstories.com/index.php?story=8 [ 3] http://www.99soft.org/ [ 4] http://99soft.github.com/guice.html [ 5] https://github.com/99soft/g-guava [ 6] https://github.com/99soft/guartz [ 7] https://github.com/99soft/GSPI [ 8] https://github.com/99soft/junice [ 9] https://github.com/99soft/lifegycle [10] https://github.com/99soft/rocoto [11] https://github.com/99soft/sli4j [12] https://github.com/99soft/gache [13] https://github.com/99soft/autobind [14] https://github.com/99soft/ http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org
Re: [DISCUSS] Apache Mayhem proposal
On 06/11/2012 12:58, Simone Tripodi wrote: Hi Eric! I tend to think that 'Less is more', that 'git is now a defacto standard', and that releasing all Mayhem components at the same time, with the same version number (even if there is no change for some of them) is easier for the user. it would be nice if they'd share a common core or if components were somehow related each other, but we don't intend to fork Google Guice and unfortunately each existing component is totally unrelated to the other :( Yes, the 11 components are unrelated, but I just find the release process such a pain that I fear to go to independent lifecycle. I can imagine many projects where all the modules/components are released even if some of them are not modified (they are just released as such). The common thing between all those components is that they ease guice usage. They are different artifacts so one has the choice to only import the artifacts he needs. Thx, Eric I asked Infra some suggestions, let see if they have more ideas! Have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [DISCUSS] Apache Mayhem proposal
Fair point Roman, the potential community/communities of developers is one of the parameter. Having a quick look at the different components dependencies, I don't see any links between them although I would have expected some of them to use sli4j for their own logging, JUnice for their unit tests... I we want to keep frontier between these components (as well on a community as on a code dependency), then one big git repo doesn't make sense. I am more interested in a unique platform based approach (although keeping the modularity). Thx, Eric On 07/11/2012 16:31, Roman Shaposhnik wrote: On Tue, Nov 6, 2012 at 1:48 PM, Eric Charles e...@apache.org wrote: Yes, the 11 components are unrelated, but I just find the release process such a pain that I fear to go to independent lifecycle. I think the real question is whether you'd expect different sub-communities of developers tending to them, or whether you'd expect a singe community where folks work on all/most of them. In my experience, the mechanical policies of releases/SCM should follow from how the community is expected to operate, not the other way around. Just my 2c. Thanks, Roman. - 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] Apache Mayhem proposal
On 04/11/2012 09:14, Simone Tripodi wrote: Salut Olivier! AFAIK not possible (git is poor for supporting such sparse checkout mode). So we (infra folks) will have to maintain one git repo per component and create a new git repo for each new component (IMHO a pain ..). In some case git is probably nice but not here ! indeed, for what I can see, not all apache-commons components are supported in git - adding an extra step, every time a new component has to be created, would be not a benefit for the project. We have very similar situation in maven projects (with some components which have their own lifecycle) and we decided to not move those parts to git. nice to see that another ASF community chan share a past similar experience! But hey what is most important build a community around cool code/projects or being able to use the last � la mode scm tool ? as I wrote in a previous message, I personally just need a SCM that allows me continue developing software in a comfortable way :) Mohammad, Eric, maybe SVN fits better for Mayhem? A git repo has to be seen like a monolithic piece of code with its full history. If Mayhem components are aiming to have completely different lifecycle with their own release independent, then many git repos would be needed. I tend to think that 'Less is more', that 'git is now a defacto standard', and that releasing all Mayhem components at the same time, with the same version number (even if there is no change for some of them) is easier for the user. But I am perfectly fine with SVN, except that we would create a structure more difficult to migrate to git later on. Thx, Eric Thanks for the feedbacks! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [DISCUSS] Apache Mayhem proposal
On 01/11/2012 20:23, Marvin Humphrey wrote: On Thu, Nov 1, 2012 at 9:11 AM, Eric Charles e...@apache.org wrote: My userid for the incubator wiki is EricCharles. Can you please add me to the ContributorsGroup? Done. Thx Marvin Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Mayhem proposal
On 02/11/2012 13:32, Mohammad Nour El-Din wrote: Hi Simone... On Fri, Nov 2, 2012 at 1:56 PM, Simone Tripodi simonetrip...@apache.orgwrote: Hi Mohammed! IMO it would be easier to move into a Git repository, which I will help in setting it up. IMO, it will also be helpful for ASF Git support to have more projects using Git which will help us understand different needs and use cases of different project to provide better Git support by time, by better I mean that now it is really good IMO but for sure we can make it better :) agreed! can you update the reference in the proposal, please? TIA!!! Sounds good. If the final state must be git, let's got directly to git. Sure thing will do it today when I have sometime The thing is we still need to have SVN for content related operations like website and so cause it needs to be published using SVN pub-sub. I will collect more details about that thanks a lot! Can we propose the site be published on Git, like we already did on GitHub in the `gh-pages` branch? WDYT? IIRC thats not possible as rge pub-sub works with SVN, to be honest I am not aware about the details thats the only fact I know about If I am wrong would someone please correct me :) ? It all depends if we want to use the Apache CMS or not. The Apache CMS is supported under by SVN-PubSub. Once again, if the final state is Apache CMS, let's go directly for it and let's not care where the content files are stored and published, that's the Apache CMS job after all (svn pubsub today, something else maybe tomorrow). If we want to rely on site generated by maven or any other command line tools, yes, it would be good to see if publication via git is supported, but as far as I know, it is not. We can always raise a request to support it but that should not block the podling. I am much more used via a Maven CLI site building and have looked to Apache CMS but didn't use it until now. All the best, -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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: [DISCUSS] Apache Mayhem proposal
I was waiting this since a long time, especially since guiceyfruit is not officially update to guice3. It's great time to do this, as more well-known 3rd parties provide their own extensions [1]. With such a good code base coming from 99soft foundation, we will be good on track. Big +1 and thx again, Eric [1] http://techblog.netflix.com/2012/10/governator-lifecycle-and-dependency.html On 31/10/2012 22:16, Christian Grobmeier wrote: I like that proposal (you have guessed it as I signed up to mentor). Guice is something cool as I found out recently. And I really like the logging component in there (surprise) On Wed, Oct 31, 2012 at 8:55 PM, Donald Whytock dwhyt...@gmail.com wrote: Just giving a post-hurricane nudge. On Tue, Oct 30, 2012 at 11:49 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I prepared a new proposal[1] for the incubator, concerning the creation of a new community focused on all aspects of Google Guice extensions, starting from a rather than small codebase that I and other friends - already ASF committers/members - would like to donate to the ASF. We still need at least one mentor, is there any volunteer available on joining to provide help on bringing that new community up? Many thanks in advance, all the best!!! -Simo [1] http://wiki.apache.org/incubator/MayhemProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Mayhem proposal
I tried to add myself to the 'Other interested people' on the wiki, but I have not the right to edit the page. Can you please add me? Unfortunately, I have not enough free slots atm to commit anything, but if you miss one mentor to reach the quorum, you can add me. I will be able to follow the project and help if needed. Is a mentor also allowed to commit? Thx, Eric On 01/11/2012 08:17, Eric Charles wrote: I was waiting this since a long time, especially since guiceyfruit is not officially update to guice3. It's great time to do this, as more well-known 3rd parties provide their own extensions [1]. With such a good code base coming from 99soft foundation, we will be good on track. Big +1 and thx again, Eric [1] http://techblog.netflix.com/2012/10/governator-lifecycle-and-dependency.html On 31/10/2012 22:16, Christian Grobmeier wrote: I like that proposal (you have guessed it as I signed up to mentor). Guice is something cool as I found out recently. And I really like the logging component in there (surprise) On Wed, Oct 31, 2012 at 8:55 PM, Donald Whytock dwhyt...@gmail.com wrote: Just giving a post-hurricane nudge. On Tue, Oct 30, 2012 at 11:49 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I prepared a new proposal[1] for the incubator, concerning the creation of a new community focused on all aspects of Google Guice extensions, starting from a rather than small codebase that I and other friends - already ASF committers/members - would like to donate to the ASF. We still need at least one mentor, is there any volunteer available on joining to provide help on bringing that new community up? Many thanks in advance, all the best!!! -Simo [1] http://wiki.apache.org/incubator/MayhemProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [DISCUSS] Apache Mayhem proposal
Hi Marvin, Definitively need to take more time to read the doc. My userid for the incubator wiki is EricCharles. Can you please add me to the ContributorsGroup? Thx, Eric On 01/11/2012 14:15, Marvin Humphrey wrote: On Thu, Nov 1, 2012 at 2:20 AM, Eric Charles e...@apache.org wrote: I tried to add myself to the 'Other interested people' on the wiki, but I have not the right to edit the page. On Thu, Nov 1, 2012 at 2:59 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: But I can't edit the wiki page at the moment would u please add me What are the user ids that you use for the Incubator wiki? (Not your apache ids, and specifically the Incubator wiki, since the id can differ across different ASF wikis.) I or someone else will add you to the ContributorsGroup as per this note: http://wiki.apache.org/incubator/ This is the Apache Wiki for the Apache Incubator and is maintained by the community. To edit pages, first sign up for a user account. Then send your username to general@incubator so that we can grant you write access by adding your account to the ContributorsGroup. Once your account is set up, just login and start making changes. Notifications of all changes you make will be sent to the cvs@incubator mailing list. Marvin Humphrey - 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] Apache Mayhem proposal
I am +1 for git. Eric On 01/11/2012 12:04, Simone Tripodi wrote: Hi Mohammad, what about having SVN+Git mirror? I personally just need a SCM, don't have a strong preference, so recommendations are more than welcome! What do you suggest? Many thanks in advance, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Nov 1, 2012 at 11:11 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi I noticed that the code is hosted on github but u r asking for an svn rep while we can have a git repo, or u don't want to continue using git ? Sent from my Samsung Galaxy S3 Apologies for any typos On Nov 1, 2012 11:59 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: Hi Simone I like the idea pretty much and I would like to be a mentor of this project. But I can't edit the wiki page at the moment would u please add me :) Thanks for bringing the project to ASF Sent from my Samsung Galaxy S3 Apologies for any typos On Nov 1, 2012 10:30 AM, Eric Charles e...@apache.org wrote: I was waiting this since a long time, especially since guiceyfruit is not officially update to guice3. It's great time to do this, as more well-known 3rd parties provide their own extensions [1]. With such a good code base coming from 99soft foundation, we will be good on track. Big +1 and thx again, Eric [1] http://techblog.netflix.com/2012/10/governator-lifecycle-and-dependency.html On 31/10/2012 22:16, Christian Grobmeier wrote: I like that proposal (you have guessed it as I signed up to mentor). Guice is something cool as I found out recently. And I really like the logging component in there (surprise) On Wed, Oct 31, 2012 at 8:55 PM, Donald Whytock dwhyt...@gmail.com wrote: Just giving a post-hurricane nudge. On Tue, Oct 30, 2012 at 11:49 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I prepared a new proposal[1] for the incubator, concerning the creation of a new community focused on all aspects of Google Guice extensions, starting from a rather than small codebase that I and other friends - already ASF committers/members - would like to donate to the ASF. We still need at least one mentor, is there any volunteer available on joining to provide help on bringing that new community up? Many thanks in advance, all the best!!! -Simo [1] http://wiki.apache.org/incubator/MayhemProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - 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: [DISCUSS] Apache Mayhem proposal
Hi Simo, oh, I forgot that mentors need to be part of IPMC. Mohammad has stepped in, so I suppose you have the quorum. Ping me if you miss one day some mentor, I would then apply to the IPMC. Thx, Eric On 01/11/2012 12:09, Simone Tripodi wrote: Hi Eric! sure I added you, I wonder why you guys don't have enough karma to edit that page :( Mentors are allowed to commit, please just let me know what you would prefer! Having you aboard, even if not really active, would still be fine; to be a mentor IIUC you have to be part of the IPMC. have a nice day, all the best! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Nov 1, 2012 at 10:20 AM, Eric Charles e...@apache.org wrote: I tried to add myself to the 'Other interested people' on the wiki, but I have not the right to edit the page. Can you please add me? Unfortunately, I have not enough free slots atm to commit anything, but if you miss one mentor to reach the quorum, you can add me. I will be able to follow the project and help if needed. Is a mentor also allowed to commit? Thx, Eric On 01/11/2012 08:17, Eric Charles wrote: I was waiting this since a long time, especially since guiceyfruit is not officially update to guice3. It's great time to do this, as more well-known 3rd parties provide their own extensions [1]. With such a good code base coming from 99soft foundation, we will be good on track. Big +1 and thx again, Eric [1] http://techblog.netflix.com/2012/10/governator-lifecycle-and-dependency.html On 31/10/2012 22:16, Christian Grobmeier wrote: I like that proposal (you have guessed it as I signed up to mentor). Guice is something cool as I found out recently. And I really like the logging component in there (surprise) On Wed, Oct 31, 2012 at 8:55 PM, Donald Whytock dwhyt...@gmail.com wrote: Just giving a post-hurricane nudge. On Tue, Oct 30, 2012 at 11:49 AM, Simone Tripodi simonetrip...@apache.org wrote: Hi all guys, I prepared a new proposal[1] for the incubator, concerning the creation of a new community focused on all aspects of Google Guice extensions, starting from a rather than small codebase that I and other friends - already ASF committers/members - would like to donate to the ASF. We still need at least one mentor, is there any volunteer available on joining to provide help on bringing that new community up? Many thanks in advance, all the best!!! -Simo [1] http://wiki.apache.org/incubator/MayhemProposal http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.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 - 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: [VOTE] Accept Blur into the Apache Incubator
[X] +1, bring Blur into Incubator Eric On 07/20/2012 06:42 PM, Aaron McCurry wrote: I would like to call a vote for accepting Blur for incubation in the Apache Incubator. The full proposal is available below. Please cast your vote: [ ] +1, bring Blur into Incubator [ ] +0, I don't care either way, [ ] -1, do not bring Blur into Incubator, because... This vote will be open for 72 hours and only votes from the Incubator PMC are binding. Thank you for your consideration! Aaron http://wiki.apache.org/incubator/BlurProposal = Blur Proposal = == Abstract == Blur is a search platform capable of searching massive amounts of data in a cloud computing environment. Blur leverages several existing Apache projects, including Apache Lucene, Apache Hadoop, Apache !ZooKeeper and Apache Thrift. Both bulk and near real time (NRT) updates are possible with Blur. Bulk updates are accomplished using Hadoop Map/Reduce and NRT are performed through direct Thrift calls. == Proposal == Blur is an open source search platform capable of querying massive amounts of data at incredible speeds. Rather than using the flat, document-like data model used by most search solutions, Blur allows you to build rich data models and search them in a semi-relational manner similar to joins while querying a relational database. Using Blur, you can get precise search results against terabytes of data at Google-like speeds. Blur leverages multiple open source projects including Hadoop, Lucene, Thrift and !ZooKeeper to create an environment where structured data can be transformed into an index that runs on a Hadoop cluster. Blur uses the power of Map/Reduce for bulk indexing into Blur. Server failures are handled automatically by using !ZooKeeper for cluster state and HDFS for index storage. == Background == Blur was created by Aaron !McCurry in 2010. Blur was developed to solve the challenges in dealing with searching huge quantities of data that the traditional RDBMS solutions could not cope with while still providing JOIN-like capabilities to query the data. Several other open source projects have implemented aspects of this design including elasticsearch, Katta and Apache Solr. == Rationale == There is a need for a distributed search capability within the Hadoop ecosystem. Currently, there are no other search solutions that natively leverage HDFS and the failover features of Hadoop in the same manner as the Blur project. The communities we expect to be most interested in such a project are government, health care, and other industries where scalability is a concern. We have made much progress in developing this project over the past 2 years and believe both the project and the interested communities would benefit from this work being openly available and having open development. In future versions of Blur the API will more closely follow the API’s provided in Lucene so that systems that already use Lucene can more easily scale with Blur. Blur can be viewed as a query execution engine that Lucene based solutions can utilize when scale becomes an issue. == Initial Goals == The initial goals of the project are: * To migrate the Blur codebase, issue tracking and wiki from github.com and integrate the project with the ASF infrastructure. * Add new committers to the project and grow the community in The Apache Way. == Current Status == === Meritocracy === Blur was initially developed by Aaron !McCurry in June 2010. Since then Blur has continued to evolve with the support of a small development team at Near Infinity. As a part of the Apache Software Foundation, the Apache Blur team intends to strongly encourage the community to help with and contribute to the project. Apache Blur will actively seek potential committers and help them become familiar with the codebase. === Community === A small community has developed around Blur and several project teams are currently using Blur for their big data search capability. The source code is currently available on GitHub and there is a dedicated website (blur.io) that provides an overview of the project. Blur has been shared with several members of the Apache community and has been presented at the Bay Area HUG (see http://www.meetup.com/hadoop/events/20109471/). === Core Developers === The current developers are employed by Near Infinity Corporation, but we anticipate interest developing among other companies. === Alignment === Blur is built on top of a number of Apache projects; Hadoop, Lucene, !ZooKeeper, and Thrift. It builds with Maven. During the course of Blur development, a couple of patches have been committed back to the Lucene project, including LUCENE-2205 and LUCENE-2215. Due to the strong relationship with the before mentioned Apache projects, the incubator is a good match for Blur. == Known Risks == === Orphaned Products === There is only a small risk of being orphaned. The customers that currently use Blur are committed to improving the codebase of the
Re: [VOTE] RC3 for Hama 0.3-incubating.
[x] +1 Release the packages as Apache Hama 0.3-incubating On 19/07/11 02:10, Edward J. Yoon wrote: Hi all, Please vote on the RC3 for Apache Hama 0.3-Incubating. We've already received 2 binding IPMC +1 votes. Vote thread: http://markmail.org/thread/eaypivg3r5wdx36y Artifact and signatures: http://people.apache.org/~edwardyoon/dist/0.3.0-RC3/ SVN Tag: https://svn.apache.org/repos/asf/incubator/hama/tags/0.3-RC3/ PGP release keys: https://svn.apache.org/repos/asf/incubator/hama/site/publish/KEYS [ ] +1 Release the packages as Apache Hama 0.3-incubating [ ] -1 Do not release the packages because... Thanks. -- Eric Charles http://about.echarles.net - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Bigtop for incubation
+1 (non-binding)
Eric
On 17/06/11 19:15, Tom White wrote:
As there are no active discussions on the proposal thread, I would
like to initiate a vote to accept Bigtop as an Apache Incubator
project.
The proposal is available at
http://wiki.apache.org/incubator/BigtopProposal?action=recallrev=13
I've also put a copy of the proposal at the end of this email.
The discussion thread is available at
http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/%3cbanlktimriyvs5g5maklqvinauz9h6s5...@mail.gmail.com%3E
Please cast your votes:
[ ] +1 Accept Bigtop for incubation
[ ] +0 Indifferent to Bigtop incubation
[ ] -1 Reject Bigtop for incubation
This vote will close 72 hours from now.
Thanks,
Tom
= Bigtop - Apache Hadoop Ecosystem Packaging and Test =
== Abstract ==
Bigtop - a project for the development of packaging and tests of the
Hadoop ecosystem.
== Proposal ==
The primary goal of Bigtop is to build a community around the
packaging and interoperability testing of Hadoop-related projects.
This includes testing at various levels (packaging, platform, runtime,
upgrade, etc...) developed by a community with a focus on the system
as a whole, rather than individual projects.
Build, packaging and integration test code that depends upon official
releases of the Apache Hadoop-related projects (HDFS, MapReduce,
HBase, Hive, Pig, ZooKeeper, etc...) will be developed and released by
this project. As bugs and other issues are found we expect these to be
fixed upstream.
== Background ==
The initial packaging and test code for Bigtop was developed by
Cloudera to package projects from the Apache Hadoop ecosystem and
provide a consistent, inter-operable framework.
== Rationale ==
Hadoop defines itself as:
{{{
The Apache Hadoop project develops open-source software for reliable,
scalable, distributed computing. Hadoop includes these subprojects:
* Hadoop Common: The common utilities that support the other Hadoop subprojects.
* HDFS: A distributed file system that provides high throughput access
to application data.
* MapReduce: A software framework for distributed processing of large
data sets on compute clusters.
}}}
There are also several other Hadoop-related projects at Apache. Some
TLP examples include HBase, Hive, Mahout, ZooKeeper, and Pig. There
are also several new projects in the Incubator such as HCatalog, Hama
and Sqoop.
From a packaging and deployment perspective, the current
loosely-coupled nature of the project has limitations:
1. Insufficient building against trunk versions of dependent projects
(in the style of Apache Gump).
1. Insufficient testing against the trunk versions of dependent projects.
1. No consistent packaging for the Linux servers which provide the
main Hadoop datacenter platform.
1. No functional testing against multi-machine clusters as part of
the regular automated build process. This is due to a lack of a
physical or virtual Hadoop cluster for testing, and not enough test
suites designed to run against a live cluster with known datasets.
The intent of this project is to build a community where the projects
are brought together, packaged, and tested for interoperability.
Projects such as Apache Whirr (incubating), which deploy and use a
collection of Hadoop-related projects, would benefit from the
interoperability testing done by Bigtop, rather than picking and
testing project combinations themselves.
== Initial Goals ==
Much of the code for Bigtop has been released by Cloudera under the
Apache 2.0 license for over two years.
Some current goals include:
* create a set of packages for the Hadoop ecosystem, over a wide
range of platforms
* interoperability test these projects
* document project sets that are known to work well together
Bigtop’s release artifact would consist of a single tarball of
packaging and test code that, when built, would produce source and
binary Linux packages for the upstream projects.
= Current Status =
== Meritocracy ==
Bigtop was originally developed and released as an open source
packaging infrastructure, CDH, by Cloudera.
== Community ==
The community is primarily the original developers at Cloudera,
however a number of contributions to the packaging specifications have
been accepted from outside contributors. Growing a diverse community
is the main reason to bring Bigtop to the Apache Incubator.
== Core Developers ==
The core developers for Bigtop project are:
* Andrew Bayer has extensive expertise with build tools, specifically
Jenkins continuous integration and Maven.
* Peter Linnell has contributed to the RPM packaging.
* Bruno Mahé has overseen much of the development of the RPM and
Debian packaging system.
* Roman Shaposhnik and Konstantin Boudnik designed and implemented
the system testing framework.
Many of the committers to the Bigtop project have contributed towards
Hadoop or related Apache projects (Alejandro Abdelnur, Konstantin
Boudnik, Eli Collins, Alan Gates, Patrick
Re: [VOTE] Accept OpenOffice.org for incubation
[x] +1 Accept OpenOffice.org for incubation Eric On 10/06/11 18:02, Sam Ruby wrote: *** Please change your Subject: line for any [DISCUSSION] of this [VOTE] As the discussions on the OpenOfficeProposal threads seem to be winding down, I would like to initiate the vote to accept OpenOffice.org as an Apache Incubator project. At the end of this mail, I've put a copy of the current proposal. Here is a link to the document in the wiki: http://wiki.apache.org/incubator/OpenOfficeProposal?action=recallrev=207 As the proposal discussion threads are numerous, I encourage people to scan and review the archives for this month: http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/browser Please cast your votes: [ ] +1 Accept OpenOffice.org for incubation [ ] +0 Indifferent to OpenOffice.org incubation [ ] -1 Reject OpenOffice.org for incubation This vote will close 72 hours from now. - Sam Ruby = OpenOffice.org - An open productivity environment = == Abstract == !OpenOffice.org is comprised of six personal productivity applications: a word processor (and its web-authoring component), spreadsheet, presentation graphics, drawing, equation editor, and database. !OpenOffice.org is released on Windows, Solaris, Linux and Macintosh operation systems, with more [[http://porting.openoffice.org/|communities]] joining, including a mature [[http://porting.openoffice.org/freebsd/|FreeBSD port]]. !OpenOffice.org is localized, supporting over 110 languages worldwide. == Proposal == Apache !OpenOffice.org will continue the mission pursued by the !OpenOffice.org project while under the sponsorship of Sun and Oracle, namely: To create, as a community, the leading international office suite that will run on all major platforms and provide access to all functionality and data through open-component based APIs and an XML-based file format. In addition to to building the !OpenOffice.org product, as an end-user facing product with many existing individual and corporate users, this project will also be active in supporting end-users via tutorials, user forums, document template repositories, etc. The project will also work to further enable !OpenOffice.org to be used as a programmable module in document automation scenarios. == Background == !OpenOffice.org was launched as an open source project by Sun Microsystems in June 2000. !OpenOffice.org was originally developed under the name of StarOffice by Star Division, a German company, which was acquired by Sun Microsystems in 1999. Sun released this as open source in 2000. !OpenOffice.org is the leading alternative to MS-Office available. Its most recent major version, the 3.x series saw over [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|100 million downloads]] in its first year. The [[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|most recent estimates]] suggest a market share on the order of 8-15%. The !OpenOffice source is written in C++ and delivers language-neutral and scriptable functionality. This source technology introduces the next-stage architecture, allowing use of the suite elements as separate applications or as embedded components in other applications. Numerous other features are also present including XML-based file formats based on the vendor-neutral !OpenDocument Format (ODF) standard from OASIS and other resources. == Rationale == !OpenOffice.org core development would continue at Apache following the contribution by Oracle, in accordance with Apache bylaws and its usual open development processes. Both Oracle and ASF agree that the !OpenOffice.org development community, previously fragmented, would re-unite under ASF to ensure a stable and long term future for OpenOffice.org. ASF would enable corporate, non-profit, and volunteer stakeholders to contribute code in a collaborative fashion. Supporting tooling projects will accompany the !OpenOffice.org contribution, providing APIs for extending and customizing !OpenOffice.org. Both !OpenOffice.org and the related tooling projects support the OASIS Open Document Format, and will attract an ecosystem of developers, ISVs and Systems Integrators. ODF ensures the users of !OpenOffice.org and related solutions will own their document data, and be free to choose the application or solution that best meets their requirements. The !OpenOffice.org implementation will serve as a reference implementation of the Open Document Format standard. = Current Status = == Meritocracy == We understand the intention and value of meritocracy at Apache. We are particularly gratified to learn, during the discussion on this proposal, that there is a strong role for non-coders to participate in this meritocracy and as they demonstrate their sustained commitment and merit, to take on additional community responsibilities. The initial developers are very familiar with open source development, both at Apache and
Re: [VOTE] Release Hama 0.2-incubating RC4
+1 Eric On 29/04/2011 13:48, Edward J. Yoon wrote: Hi, I just uploaded the RC4 for Hama 0.2.0. This RC fixes license problem by removing useless dependencies. Artifact and signatures: http://people.apache.org/~edwardyoon/dist/0.2.0-RC4/ SVN Tag: https://svn.apache.org/repos/asf/incubator/hama/tags/0.2-RC4/ Please vote on this release. Changes for this release: UNOTICE.txt ULICENSE.txt Dconf/findbugs-exclude-filter.xml Dlib/commons-httpclient-3.0.1.jar Dlib/jasper-runtime-5.5.12.jar Dlib/UmlGraph.jar Dlib/jasper-compiler-5.5.12.jar Dlib/servlet-api-2.5-6.1.14.jar Upom.xml Ubuild.xml Thanks. Sent from my iPad - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Hama version 0.2-incubating (second)
[x] +1 Release the packages as Apache Hama 0.2-incubating (non-binding) Tks, - Eric Hi IPMCers and Incubator community, The previous mentioned problems (e.g., license, notice, disclaimer, and website logo/text) are all fixed and I just created RC3. There'are only changes of text, no changes at the code level. Hama Website: http://incubator.apache.org/hama The release artifact, sums, GPG key and signature: http://people.apache.org/~edwardyoon/dist/0.2.0-RC3/ Subversion tag for release: https://svn.apache.org/repos/asf/incubator/hama/tags/0.2-RC3/ Please vote again on this thread! [ ] +1 Release the packages as Apache Hama 0.2-incubating [ ] -1 Do not release the packages because... Thanks in advance!! -- Best Regards, Edward J. Yoon http://blog.udanax.org http://twitter.com/eddieyoon - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
