Re: [PROPOSAL] Provisionr join the Apache Incubator
Hi I would like to help and hence added myself as a mentor. Thanks for bringing the project to Apache. On Fri, Mar 1, 2013 at 7:02 AM, Andrei Savu savu.and...@gmail.com wrote: Hi David - On Thu, Feb 28, 2013 at 11:19 AM, David Nalley da...@gnsa.us wrote: I am interested in this. I know one or two things about puppet and cloud APIs. Not sure how many cycles I can expend. It would be great to have you part of the team. Feel free to edit the wiki. CloudStack support is very important for me and I'm going to spend a fair amount of time on that over the next cloud of weeks / months. -- Andrei Savu -- Thanks - Mohammad Nour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein
Re: [VOTE] Accept Tajo into the Apache Incubator
On 28 February 2013 18:11, Hyunsik Choi hyun...@apache.org wrote: Hi Folks, I'd like to call a VOTE for acceptance of Tajo into the Apache incubator. The vote will close on Mar 7 at 6:00 PM (PST). [X] +1 Accept Tajo into the Apache incubator [] +0 Don't care. [] -1 Don't accept Tajo into the incubator because... +1, binding. It'll not only move the hadoop stack up, but act as more regression tests to the layers below. And test are always welcome
Re: [PROPOSAL] Provisionr join the Apache Incubator
On 27 February 2013 18:53, Andrei Savu savu.and...@gmail.com wrote: Hi Benson - Thanks for your feedback! It's too early to decide if there is an overlap between communities. Provisionr solves a different problem being focused on semi-automated workflows (e.g. with Rundeck) and cloud portability while Whirr is more focused on deploying services from the Hadoop stack. I had this conversation before with Tom. -- Andrei Savu I do support this, though lack time to commit to active participation. It is very different from whirr, but is built very much on other bits of the ASF codebase, especially Karaf. One thing I would recommend for the curious is to get a demo of it from Andrei; I saw one over G+ and it looked very nice. -Steve
Re: [PROPOSAL] Curator for the Apache Incubator
Chris, I added a line to the Alignment section. Let me know if it's OK. -JZ On Feb 26, 2013, at 1:23 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: I would appreciate at some level a note in your proposal regarding at least the concern by one member of the IPMC that Curator should grow into its own TLP rather than be a part of ZK should it be accepted. - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Wed, Feb 27, 2013 at 1:21 AM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Dave, On 2/26/13 4:18 PM, Dave Fisher dave2w...@comcast.net wrote: This is exactly the scenario I have in mind. Most of the times, projects aim for being very successful and have their own healthy community, but that is not always the outcome, and exiting Incubator as an adopted project should be still be a possibility. I don't think we should exclude incubating projects from being incorporated into other projects. It may be preferred to the attic or github should a community fail to thrive. The incubator does not need to be TLP or fail. Perhaps the assimilation of an incubating podling to another PMC should not be called graduation. Maybe it should be handled piece by piece. (1) PPMC votes to approach a PMC with Mentor / IPMC approval like for a release. Please name me a specific example scenario in which #1 has happened at the ASF without pre stated intent to join that TLP. Sanselan graduated to Apache Commons is an example of this. Niall I would be very surprised to see it happen b/c it would imply graduation into an existing TLP wasn't premeditated. That's the whole point of the sponsoring PMC portion of the Incubator proposal, from the beginning, to declare the intent to graduate into a existing TLP - otherwise that section wouldn't be needed and the answer would always be Incubator PMC. For the record, since the whole umbrella project thing, most of the sponsoring (I can name perhaps 1-5) incoming Incubator podlings are all Incubator PMC sponsored, for intent to graduate to TLP. On the graduating into existing TLP end, I don't think that makes sense - apparently at least 2 other people don't either judging by +1s and words. I would like to fix that. But, I don't think I've ever seen #1 where they haven't already declared that their intent from the beginning. (2) Receiving PMC votes to accept IP - if not cleared then it accepts that responsibility. If PMCs can accept the type of podling sized IP contribution then I think that the Incubator is a pointless committee. Cheers, Chris - 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: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Niall I'd like to suggest two changes: 1) Incubation is for new TLPs only. Turn off the graduate-into-TLP option. 2) Move the short form IP clearance to Legal Affairs, to clarify that we're only talking IP, rather than other concerns. Cheers, -g On Feb 26, 2013 4:19 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Hi Luciano, On 2/26/13 12:03 PM, Luciano Resende luckbr1...@gmail.com wrote: +1, We don't need to discuss exit criteria before entering incubation. Actually we do and I can. Else I'm pretty useless on the IPMC. I just went through an experience where my objection/VOTE didn't really mean anything in a situation that I didn't think was correct (see HCatalog/Hive). I will be darned sure to discuss exit criteria now as I wish I would have paid attention and done so then, would have saved hassle all around. And if the Zookeeper PMC wants to adopt Curator as part of the Zookeeper project (see distinction from sub-project language, which is what the Board does not favor), they can work with the community and do it Define working with the community. My definition of that doesn't include entering the Incubator. My definition of that means, Pat or someone else on the ZK PMC starts getting Curator patches and/or committing them and Jordan or Jay become Committers/PMC members on ZK because of those contributions (and have their ICLAs on file, etc.) Having said that, the exit criteria should really be an option instead of being dictated. I'm questioning graduation to an existing TLP (and not as a new one) as a valid exit criteria of the Incubator. I don't think it makes sense. Cheers, Chris - 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 Tajo into the Apache Incubator
+1 (binding) On Sat, Mar 2, 2013 at 2:16 AM, Roman Shaposhnik ro...@shaposhnik.orgwrote: +1 (binding). I would also encourage you guys to take a look at Apache Bigtop as a way of integrating with the rest of Hadoop ecosystem and bring more testing into the fold. Looking forward to working with you! Thanks, Roman. On Thu, Feb 28, 2013 at 10:11 AM, Hyunsik Choi hyun...@apache.org wrote: Hi Folks, I'd like to call a VOTE for acceptance of Tajo into the Apache incubator. The vote will close on Mar 7 at 6:00 PM (PST). [] +1 Accept Tajo into the Apache incubator [] +0 Don't care. [] -1 Don't accept Tajo into the incubator because... Full proposal is pasted at the bottom on this email, and the corresponding wiki is http://wiki.apache.org/incubator/TajoProposal. Only VOTEs from Incubator PMC members are binding, but all are welcome to express their thoughts. Thanks, Hyunsik PS: From the initial discussion, the main changes are that I've added 4 new committers. Also, I've revised some description of Known Risks because the initial committers have been diverse. Tajo Proposal = Abstract = Tajo is a distributed data warehouse system for Hadoop. = Proposal = Tajo is a relational and distributed data warehouse system for Hadoop. Tajo is designed for low-latency and scalable ad-hoc queries, online aggregation and ETL on large-data sets by leveraging advanced database techniques. It supports SQL standards. Tajo is inspired by Dryad, MapReduce, Dremel, Scope, and parallel databases. Tajo uses HDFS as a primary storage layer, and it has its own query engine which allows direct control of distributed execution and data flow. As a result, Tajo has a variety of query evaluation strategies and more optimization opportunities. In addition, Tajo will have a native columnar execution and and its optimizer. Tajo will be an alternative choice to Hive/Pig on the top of MapReduce. = Background = Big data analysis has gained much attention in the industrial. Open source communities have proposed scalable and distributed solutions for ad-hoc queries on big data. However, there is still room for improvement. Markets need more faster and efficient solutions. Recently, some alternatives (e.g., Cloudera's Impala and Amazon Redshift) have come out. = Rationale = There are a variety of open source distributed execution engines (e.g., hive, and pig) running on the top of MapReduce. They are limited by MR framework. They cannot directly control distributed execution and data flow, and they just use MR framework. So, they have limited query evaluation strategies and optimization opportunities. It is hard for them to be optimized for a certain type of data processing. = Initial Goals = The initial goal is to write more documents to describe Tajo's internal. It will be helpful to recruit more committers and to build a solid community. Then, we will make milestones for short/long term plans. = Current Status = Tajo is in the alpha stage. Users can execute usual SQL queries (e.g., selection, projection, group-by, join, union and sort) except for nested queries. Tajo provides various row/column storage formats, such as CSV, RowFile (a row-store file we have implemented), RCFile, and Trevni, and it also has a rudimentary ETL feature to transform one data format to another data format. In addition, Tajo provides hash and range repartitions. By using both repartition methods, Tajo processes aggregation, join, and sort queries over a number of cluster nodes. To evaluate the performance, we have carried out benchmark test using TPC-H 1TB on 32 cluster nodes. == Meritocracy == We will discuss the milestone and the future plan in an open forum. We plan to encourage an environment that supports a meritocracy. The contributors will have different privileges according to their contributions. == Community == Big data analysis has gained attention from open source communities, industrial and academic areas. Some projects related to Hadoop already have very large and active communities. We expect that Tajo also will establish an active community. Since Tajo already works for some features and is in the alpha stage, it will attract a large community soon. == Core Developers == Core developers are a diverse group of developers, many of which are very experienced in open source and the Apache Hadoop ecosystem. * Eli Reisman ereisman AT apache DOT org * Henry Saputra hsaputra AT apache DOT org * Hyunsik Choi hyunsik AT apache DOT org * Jae Hwa Jung jhjung AT gruter DOT com * Jihoon Son ghoonson AT gmail DOT com * Jin Ho Kim jhkim AT gruter DOT com * Roshan Sumbaly rsumbaly AT gmail DOT com * Sangwook Kim swkim AT inervit DOT com * Yi A Liu yi DOT a DOT liu AT intel DOT
Re: [PROPOSAL] Provisionr join the Apache Incubator
On Fri, Mar 1, 2013 at 12:59 AM, Mohammad Nour El-Din nour.moham...@gmail.com wrote: I would like to help and hence added myself as a mentor. Thanks for bringing the project to Apache. Thanks for joining! Your help is highly appreciated. -- Andrei Savu
Re: [PROPOSAL] Provisionr join the Apache Incubator
Thanks Steve! On Fri, Mar 1, 2013 at 3:43 AM, Steve Loughran steve.lough...@gmail.comwrote: One thing I would recommend for the curious is to get a demo of it from Andrei; I saw one over G+ and it looked very nice. Anyone should feel free to email me if they want a live demo. -- Andrei Savu
Re: [PROPOSAL] Provisionr join the Apache Incubator
On Fri, Mar 1, 2013 at 10:45 AM, Eric Sammer esam...@cloudera.com wrote: I'd love to be involved if you're actively looking for initial committers. I'm very familiar with OSGi, puppet, and the Hadoop ecosystem side of things. I'm (non-binding) +1 on accepting the project to the incubator. Thanks Eric and welcome to the team. -- Andrei Savu
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
On Mar 1, 2013 8:33 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Yup. The Incubator doesn't have staff. It really doesn't make sense to put a community in their hands. Either a community self-builds, or it should become part of an existing community. For the WebWorks case, I would rather have seen them get a branch in Struts. Over time, the features would get integrated from the branch to trunk, and the committers would get expanded commit access. I understand a project may arrive, thinking to become a TLP, but later change their desired exit. But I think it would be best to call that an exception. Instead, we let target communities directly teach the incomers about operating within their (our ASF-style) community. Cheers, -g
Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)
Hi Niall, and Greg, Just to echo Greg, +1, yes would have preferred it to have happened in the existing community then. Also, agree with Greg -- exceptions can be permitted from time to time, but I don't think graduation into existing TLP should be an accepted norm. Cheers, Chris On 3/1/13 8:55 PM, Greg Stein gst...@gmail.com wrote: On Mar 1, 2013 8:33 PM, Niall Pemberton niall.pember...@gmail.com wrote: On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein gst...@gmail.com wrote: I concur with Chris, and want to strengthen/meta the point. The Incubator should not be used for projects which are intended to become part of an existing TLP. The Incubator *creates* Apache-style communities. But... Stop. For these, we don't want a separate/new community. They are supposed to be *part of* the existing TLP. Thus, they have no business here. They should start within the target TLP. The incubation of WebWork into Struts is an example where there was an existing project outside the ASF with an existing bunch of developers that were not ASF committers. The point of going through the incubator was for the communities to merge. I guess at the time we could have just given comitt access to all WebWork devs - but most of us on the Struts project didn't know them. Is that what you're proposing should happen in this scenario? Yup. The Incubator doesn't have staff. It really doesn't make sense to put a community in their hands. Either a community self-builds, or it should become part of an existing community. For the WebWorks case, I would rather have seen them get a branch in Struts. Over time, the features would get integrated from the branch to trunk, and the committers would get expanded commit access. I understand a project may arrive, thinking to become a TLP, but later change their desired exit. But I think it would be best to call that an exception. Instead, we let target communities directly teach the incomers about operating within their (our ASF-style) community. Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
