Re: [VOTE] Release Apache Tajo-0.2-incubating RC3
+1 (binding). Verified MD5. License, disclaimer and notice all look good. On Tue, Nov 12, 2013 at 8:07 PM, Hyunsik Choi hyun...@apache.org wrote: Ping - just a friendly reminder that we're seeking votes on our first release here. - hyunsik On Sun, Nov 10, 2013 at 2:46 PM, Hyunsik Choi hyun...@apache.org wrote: Dear IPMC members, If there are some reasons why you do not vote, please leave reasons here. I would like to proceed or cancel this vote. Best regards, Hyunsik Choi On Thu, Nov 7, 2013 at 11:59 AM, Hyunsik Choi hyun...@apache.org wrote: Are there other IPMC members who are willing to review this release? We need two more votes! - hyunsik 2013년 11월 4일 월요일에 Hyunsik Choi님이 작성: Hi folks This is the fourth candidate for Apache Tajo-0.2-incubating, and it is also the first official release for Tajo. The PPMC vote [1][2][3] was passed with 3 binding +4s and no -1. Release git tag is at: https://git-wip-us.apache.org/repos/asf?p=incubator-tajo.git;a=shortlog;h=refs/tags/release-0.2.0-rc3 Release notes is at: http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/RELEASE_NOTES.html Release artifacts, signatures, md5, and sha1 are at: http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/ and the KEYS file containing the PGP keys used to sign the release can currently be found at: http://people.apache.org/keys/group/tajo.asc The RAT report is at: http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/rat.txt Please vote [ ] +1 release this package as apache-tajo-0.2-incubating [ ] -1 do not release this package because ... Thanks, Hyunsik Choi [1] http://markmail.org/message/cvwzgdfkq2zfmmbo [2] http://markmail.org/message/crhbpagwo3pvm4et [3] http://markmail.org/message/kofx3nfjzcr7chqu - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On Tue, Nov 12, 2013 at 11:58 PM, ant elder ant.el...@gmail.com wrote: So, we _can_ let podlings have their own binding release votes and we could do our own pTLP type experiments without even needing to go to the board. We should try that. Not for every podling but just for select ones where the circumstances mean it will work better than the current approach. If there are no major objections to some experiments with this approach then i'd like to start trying one. +1 to run an experiment. The position that Roy has taken changes the equation. While a number of people have expressed a preference for the approach of electing more podling contributors directly onto the IPMC, in practice it remains uncertain whether the IPMC is capable of identifying, nominating and voting in enough candidates -- as evidenced by some threads currently in progress on private@incubator. I propose that the experiment take the following form: 1. The initial PPMC shall be composed exclusively of IPMC members. 2. PPMC votes are binding for every release except the first. 3. One IPMC vote is required for each release after the first. I believe that this model provides sufficient oversight because the first release must cross a high bar, and because it changes the dynamics of electing PPMC members: even core contributors will now have to earn PPMC membership, demonstrating to an initial PPMC composed of IPMC members that they understand the Apache Way well enough to steward their project. Marvin Humphrey - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On Wed, Nov 13, 2013, at 06:14 PM, Marvin Humphrey wrote: On Tue, Nov 12, 2013 at 11:58 PM, ant elder ant.el...@gmail.com wrote: So, we _can_ let podlings have their own binding release votes and we could do our own pTLP type experiments without even needing to go to the board. We should try that. Not for every podling but just for select ones where the circumstances mean it will work better than the current approach. If there are no major objections to some experiments with this approach then i'd like to start trying one. +1 to run an experiment. The position that Roy has taken changes the equation. While a number of people have expressed a preference for the approach of electing more podling contributors directly onto the IPMC, in practice it remains uncertain whether the IPMC is capable of identifying, nominating and voting in enough candidates -- as evidenced by some threads currently in progress on private@incubator. I propose that the experiment take the following form: 1. The initial PPMC shall be composed exclusively of IPMC members. 2. PPMC votes are binding for every release except the first. 3. One IPMC vote is required for each release after the first. I believe that this model provides sufficient oversight because the first release must cross a high bar, and because it changes the dynamics of electing PPMC members: even core contributors will now have to earn PPMC membership, demonstrating to an initial PPMC composed of IPMC members that they understand the Apache Way well enough to steward their project. I would be very supportive of such an experiment. Make the size of the merit granted fit the stage at which an individual is at. I presume #4 is: Three +1 votes from PPMC members required. Upayavira - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On 11/13/13 10:14 AM, Marvin Humphrey mar...@rectangular.com wrote: While a number of people have expressed a preference for the approach of electing more podling contributors directly onto the IPMC, in practice it remains uncertain whether the IPMC is capable of identifying, nominating and voting in enough candidates -- as evidenced by some threads currently in progress on private@incubator. I propose that the experiment take the following form: 1. The initial PPMC shall be composed exclusively of IPMC members. 2. PPMC votes are binding for every release except the first. 3. One IPMC vote is required for each release after the first. I believe that this model provides sufficient oversight because the first release must cross a high bar, and because it changes the dynamics of electing PPMC members: even core contributors will now have to earn PPMC membership, demonstrating to an initial PPMC composed of IPMC members that they understand the Apache Way well enough to steward their project. Isn't there a possible bug here where given a higher bar for entry to the PPMC (you would now have to prove you understand the legal aspects of Apache releases before you can get on the PPMC) that it will burden the IPMC folks on the PPMC because they are the only ones who can cast votes to accept new committers, and if a first release happens but there's only one newbie who truly gets the legal aspects that the PPMC only grows by 1 and can still be left hanging if the IPMC folks walk away? I still think that having a Release Auditor role provides backup for getting incubator releases out without having folks have to be on the IPMC to approve the legal aspects of a release. Just like any ASF Member can backup busy PMC Chairs for some actions, any TLP PMC member should be able to backup a busy IPMC member for release auditing. -Alex - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Cultivating Outstanding IP Stewards
On Nov 13, 2013, at 1:14 PM, Marvin Humphrey mar...@rectangular.com wrote: On Tue, Nov 12, 2013 at 11:58 PM, ant elder ant.el...@gmail.com wrote: So, we _can_ let podlings have their own binding release votes and we could do our own pTLP type experiments without even needing to go to the board. We should try that. Not for every podling but just for select ones where the circumstances mean it will work better than the current approach. If there are no major objections to some experiments with this approach then i'd like to start trying one. +1 to run an experiment. The position that Roy has taken changes the equation. While a number of people have expressed a preference for the approach of electing more podling contributors directly onto the IPMC, in practice it remains uncertain whether the IPMC is capable of identifying, nominating and voting in enough candidates -- as evidenced by some threads currently in progress on private@incubator. I propose that the experiment take the following form: 1. The initial PPMC shall be composed exclusively of IPMC members. 2. PPMC votes are binding for every release except the first. 3. One IPMC vote is required for each release after the first. I believe that this model provides sufficient oversight because the first release must cross a high bar, and because it changes the dynamics of electing PPMC members: even core contributors will now have to earn PPMC membership, demonstrating to an initial PPMC composed of IPMC members that they understand the Apache Way well enough to steward their project. + 1, I like this balance and caveats. In my personal view (which I am not generalizing), getting the first release is very time consuming but educational and very much worth it. I do not look at it as one month or so for a release is unreasonable, but rather think it as, one month amortized over quality subsequent releases. Which ever approach or policy changes we take, we still need patient incumbents and overly patient mentors. The only way mentors scale is to teach the process and groom new teachers. Ofcourse not many students will like the teachers until they also become teachers. Atleast this happened to me, I appreciate my mentors more now then when I was a student :) Suresh 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
[PROPOSAL] Phoenix for Incubation
Hi All, We're pleased to share a draft ASF incubation proposal for Phoenix, a SQL layer over HBase, initially developed at Salesforce.com and subsequently open sourced on github (https://github.com/forcedotcom/phoenix). Instead of using Map-reduce to processes queries, it compiles SQL directly into native HBase calls. The complete proposal can be found here: https://wiki.apache.org/incubator/PhoenixProposal, and is also pasted below. Your feedback is greatly appreciated. James == Abstract == Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data store. It is accessed as a JDBC driver and enables querying and managing HBase tables using SQL. == Proposal == Phoenix is an open source SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Phoenix interfaces with both Pig and Map-reduce for the input and output of data. == Background == Phoenix initially started as an internal project at Salesforce.com to efficiently analyze big data stored in HBase. It was open sourced on Github about a year ago in Jan 2013. Over time Phoenix, together with HBase as the storage tier, has begun to evolve into a general SQL database with support for metadata management, secondary indexes, joins, query optimization, and multi-tenancy. This is expected to continue as Phoenix implements a cost-based query optimizer and potentially transaction support, and surfaces new HBase security features such as encryption and cell-level security. Phoenix's developer community has also grown to include additional companies such as Intel, who have contributed join support to Phoenix, as well as Hortonworks, who are in the process of porting Phoenix to the 0.96 release of HBase. == Rationale == As usage and the number of contributors to Phoenix has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Joining Apache would ensure that tried and true processes and procedures are in place for the growing number of organizations interested in contributing to Phoenix. Phoenix is also a good fit for the Apache foundation: Phoenix already interoperates with several existing Apache projects (HBase, Hadoop, Pig). The Phoenix team is familiar with the Apache process and and believes in the Apache mission - the team already includes multiple Apache committers. == Initial Goals == The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. == Current Status == Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, 2.0, and 2.1) as well as many patch releases. Phoenix is being used in production by Salesforce.com as well as at other organizations. The Phoenix codebase is currently hosted at github.com, which will form the basis of the Apache git repository. === Meritocracy === The Phoenix project already operates on meritocratic principles. Phoenix has several developers from various organizations outside of Salesforce.com who have contributed major new features. While this process has remained mostly informal, as we do not have an official committer list, an implicit organization exists in which individuals who contribute major components act as maintainers for those modules. If accepted, the Phoenix project would include several of these participants as initial committers. We will work to identify all committers and PPMC members for the project and to operate under the ASF meritocratic principles. === Community === Acceptance into the Apache foundation would bolster the already strong user and developer community around Phoenix. That community includes many contributors from various other companies, and an active mailing list composed of hundreds of users. === Core Developers === The core developers of our project are listed in our contributors and initial PPMC below. Though many are employed at Salesforce.com, there is a representative cross sampling of other organizations including Intel, Hortonworks, Cloudera, and Twitter. === Alignment === Our proposed Phoenix effort aligns closely with Apache HBase. The HBase project perimeter is denoted by a simple byte-array based Create, Read, Update, Delete and Scan APIs with no current plans to extend beyond this bounds. Phoenix complements this with a higher level API in SQL with which many are
Re: [DISCUSS] [VOTE] Accept Twill for Incubation
Sounds good, we will continue the process with the proposed name Twill. Thanks -Andreas. On Tue, Nov 12, 2013 at 5:18 PM, Henry Saputra henry.sapu...@gmail.comwrote: We had similar issue with MetaModel where there are a lot of projects with name MetaModel but the name was approved given it needs to always mentioned as Apache MetaModel. I think we could do similar approach with Twill? - Henry On Tue, Nov 12, 2013 at 2:53 PM, Andreas Neumann a...@apache.org wrote: This is valuable feedback, and I am not quite sure how to deal with this after the vote has already passed. I took a look at retwill, and it seems that it has not had any activity (wiki edits, issues, pull requests, releases, commits) for about 18 months. In fact, it appears that it was abandoned in May 2012, only two months after it was created in March of the same year. What is the general feeling on this list? Is it a strong enough conflict to require a different project name? Thanks -Andreas. On Tue, Nov 12, 2013 at 1:45 PM, Olemis Lang ole...@gmail.com wrote: On Fri, Nov 8, 2013 at 2:25 PM, Andreas Neumann a...@apache.org wrote: Andrea, thanks for the link, we did see that project but thought that it is not relevant because it has not had any activity for 6 years, so it is probably dead. Should we be more concerned about this? There is a continuation (fork) named retwill [1]_ . BTW twill is a dependency to run the test suite of Apache™ Bloodhound . IMO , I do not think twill is a suitable name . It's very spread and popular in some circle . Choosing that name might cause some confusion . .. [1] https://bitbucket.org/brandizzi/retwill .. [2] http://shop.oreilly.com/product/9780596527808.do [...] -- Regards, Olemis - @olemislc Apache™ Bloodhound contributor http://issues.apache.org/bloodhound http://blood-hound.net Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Tajo-0.2-incubating RC3
+1 (binding) On 14 November 2013 03:23, Jakob Homan jgho...@gmail.com wrote: +1 (binding). Verified MD5. License, disclaimer and notice all look good. On Tue, Nov 12, 2013 at 8:07 PM, Hyunsik Choi hyun...@apache.org wrote: Ping - just a friendly reminder that we're seeking votes on our first release here. - hyunsik On Sun, Nov 10, 2013 at 2:46 PM, Hyunsik Choi hyun...@apache.org wrote: Dear IPMC members, If there are some reasons why you do not vote, please leave reasons here. I would like to proceed or cancel this vote. Best regards, Hyunsik Choi On Thu, Nov 7, 2013 at 11:59 AM, Hyunsik Choi hyun...@apache.org wrote: Are there other IPMC members who are willing to review this release? We need two more votes! - hyunsik 2013년 11월 4일 월요일에 Hyunsik Choi님이 작성: Hi folks This is the fourth candidate for Apache Tajo-0.2-incubating, and it is also the first official release for Tajo. The PPMC vote [1][2][3] was passed with 3 binding +4s and no -1. Release git tag is at: https://git-wip-us.apache.org/repos/asf?p=incubator-tajo.git;a=shortlog;h=refs/tags/release-0.2.0-rc3 Release notes is at: http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/RELEASE_NOTES.html Release artifacts, signatures, md5, and sha1 are at: http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/ and the KEYS file containing the PGP keys used to sign the release can currently be found at: http://people.apache.org/keys/group/tajo.asc The RAT report is at: http://people.apache.org/~hyunsik/tajo-0.2.0-incubating-rc3/rat.txt Please vote [ ] +1 release this package as apache-tajo-0.2-incubating [ ] -1 do not release this package because ... Thanks, Hyunsik Choi [1] http://markmail.org/message/cvwzgdfkq2zfmmbo [2] http://markmail.org/message/crhbpagwo3pvm4et [3] http://markmail.org/message/kofx3nfjzcr7chqu - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Accept Twill for Incubation
+1 St.Ack On Thu, Nov 7, 2013 at 1:04 PM, Andreas Neumann a...@apache.org wrote: The discussion about the Weave proposal has calmed. As the outcome of the discussion, we have chosen a new name for the project, Twill. I would like to call a vote for Twill to become an incubated project. The proposal is pasted below, and also available at: https://wiki.apache.org/incubator/TwillProposal Let's keep this vote open for three business days, closing the voting on Tuesday 11/12. [ ] +1 Accept Twill into the Incubator [ ] +0 Don't care. [ ] -1 Don't accept Twill because... -Andreas. = Abstract = Twill is an abstraction over Apache Hadoop® YARN that reduces the complexity of developing distributed applications, allowing developers to focus more on their business logic. = Proposal = Twill is a set of libraries that reduces the complexity of developing distributed applications. It exposes the distributed capabilities of Apache Hadoop® YARN via a simple and intuitive programming model similar to Java threads. Twill also has built-in capabilities required by many distributed applications, such as real-time application logs and metrics collection, application lifecycle management, and network service discovery. = Background = Hadoop YARN is a generic cluster resource manager that supports any type of distributed application. However, YARN’s interfaces are too low level for rapid application development. It requires a great deal of boilerplate code even for a simple application, creating a high ramp up cost that can turn developers away. Twill is designed to improve this situation with a programming model that makes running distributed applications as easy as running Java threads. With the abstraction provided by Twill, applications can be executed in process threads during development and unit testing and then be deployed to a YARN cluster without any modifications. Twill also has built-in support for real-time application logs and metrics collection, delegation token renewal, application lifecycle management, and network service discovery. This greatly reduces the pain that developers face when developing, debugging, deploying and monitoring distributed applications. Twill is not a replacement for YARN, it’s a framework that operates on top of YARN. = Rationale = Developers who write YARN applications typically find themselves implementing the same (or similar) boilerplate code over and over again for every application. It makes sense to distill this common code into a reusable set of libraries that is perpetually maintained and improved by a diverse community of developers. Twill’s simple thread-like programming model will enable many Java programmers to develop distributed applications. We believe that this simplicity will attract developers who would otherwise be discouraged by complexity, and many new use cases will emerge for the usage of YARN. Incubating Twill as an Apache project makes sense because Twill is a framework built on top of YARN, and Twill uses Apache Zookeeper, HDFS, Kafka, and other Apache software (see the External Dependencies section). = Current Status = Twill was initially developed at Continuuity under the name of Weave. The Weave codebase is currently hosted in a public repository at github.com, which will seed the Apache git repository after renaming to Twill. == Meritocracy == Our intent with this incubator proposal is to start building a diverse developer community around Twill following the Apache meritocracy model. Since Twill was initially developed in early 2013, we have had fast adoption and contributions within Continuuity. We are looking forward to new contributors. We wish to build a community based on Apache's meritocracy principles, working with those who contribute significantly to the project and welcoming them to be committers both during the incubation process and beyond. == Community == Twill is currently being used internally at Continuuity and is at the core of our products. We hope to extend our contributor base significantly and we will invite all who are interested in simplifying the development of distributed applications to participate. == Core Developers == Twill is currently being developed by five engineers at Continuuity: Terence Yim, Andreas Neumann, Gary Helmling, Poorna Chandra and Albert Shau. Terence Yim is an Apache committer for Helix, Andreas is an Apache committer and PMC member for Oozie, and Gary Helmling is an Apache committer and PMC member for HBase. Poorna Chandra and Albert Shau have made many contributions to Twill. == Alignment == The ASF is the natural choice to host the Twill project as its goal of encouraging community-driven open source projects fits with our vision for Twill. Additionally, many other projects with which we are familiar and expect Twill to integrate with, such as ZooKeeper, YARN, HDFS, log4j, and others
Re: [PROPOSAL] Phoenix for Incubation
Phoenix is a great addition as sub-project of HBase. +1 from me. Thanks, Anil Gupta - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Phoenix for Incubation
It is indeed very specific for HBase use I suppose. Would it be more beneficial to make it sub-project of HBase to get full community support from HBase? On Wed, Nov 13, 2013 at 12:43 PM, James Taylor jtay...@salesforce.com wrote: Hi All, We're pleased to share a draft ASF incubation proposal for Phoenix, a SQL layer over HBase, initially developed at Salesforce.com and subsequently open sourced on github (https://github.com/forcedotcom/phoenix). Instead of using Map-reduce to processes queries, it compiles SQL directly into native HBase calls. The complete proposal can be found here: https://wiki.apache.org/incubator/PhoenixProposal, and is also pasted below. Your feedback is greatly appreciated. James == Abstract == Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data store. It is accessed as a JDBC driver and enables querying and managing HBase tables using SQL. == Proposal == Phoenix is an open source SQL skin over HBase delivered as a client-embedded JDBC driver targeting low latency queries over HBase data. Phoenix takes your SQL query, compiles it into a series of HBase scans, and orchestrates the running of those scans to produce regular JDBC result sets. The table metadata is stored in an HBase table and versioned, such that snapshot queries over prior versions will automatically use the correct schema. Direct use of the HBase API, along with coprocessors and custom filters, results in performance on the order of milliseconds for small queries, or seconds for tens of millions of rows. Phoenix interfaces with both Pig and Map-reduce for the input and output of data. == Background == Phoenix initially started as an internal project at Salesforce.com to efficiently analyze big data stored in HBase. It was open sourced on Github about a year ago in Jan 2013. Over time Phoenix, together with HBase as the storage tier, has begun to evolve into a general SQL database with support for metadata management, secondary indexes, joins, query optimization, and multi-tenancy. This is expected to continue as Phoenix implements a cost-based query optimizer and potentially transaction support, and surfaces new HBase security features such as encryption and cell-level security. Phoenix's developer community has also grown to include additional companies such as Intel, who have contributed join support to Phoenix, as well as Hortonworks, who are in the process of porting Phoenix to the 0.96 release of HBase. == Rationale == As usage and the number of contributors to Phoenix has grown, we have sought for a long-term home for the project, and we believe the Apache foundation would be a great fit. Joining Apache would ensure that tried and true processes and procedures are in place for the growing number of organizations interested in contributing to Phoenix. Phoenix is also a good fit for the Apache foundation: Phoenix already interoperates with several existing Apache projects (HBase, Hadoop, Pig). The Phoenix team is familiar with the Apache process and and believes in the Apache mission - the team already includes multiple Apache committers. == Initial Goals == The initial goals will be to move the existing codebase to Apache and integrate with the Apache development process. Once this is accomplished, we plan for incremental development and releases that follow the Apache guidelines. == Current Status == Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2, 2.0, and 2.1) as well as many patch releases. Phoenix is being used in production by Salesforce.com as well as at other organizations. The Phoenix codebase is currently hosted at github.com, which will form the basis of the Apache git repository. === Meritocracy === The Phoenix project already operates on meritocratic principles. Phoenix has several developers from various organizations outside of Salesforce.com who have contributed major new features. While this process has remained mostly informal, as we do not have an official committer list, an implicit organization exists in which individuals who contribute major components act as maintainers for those modules. If accepted, the Phoenix project would include several of these participants as initial committers. We will work to identify all committers and PPMC members for the project and to operate under the ASF meritocratic principles. === Community === Acceptance into the Apache foundation would bolster the already strong user and developer community around Phoenix. That community includes many contributors from various other companies, and an active mailing list composed of hundreds of users. === Core Developers === The core developers of our project are listed in our contributors and initial PPMC below. Though many are employed at Salesforce.com, there is a representative cross sampling of other organizations including Intel, Hortonworks, Cloudera, and Twitter. ===
Re: [PROPOSAL] Phoenix for Incubation
Hi All, I am sorry for the confusion. I didn't mean to say that Phoenix should be a sub-project of Apache HBase. My +1 for Phoenix as Top Level Project. At Intuit, we have been extensively using Phoenix. Thanks, Anil Gupta Software Engineer, Intuit Inc On Wed, Nov 13, 2013 at 10:31 PM, Anil Gupta anilgupt...@gmail.com wrote: Phoenix is a great addition as sub-project of HBase. +1 from me. Thanks, Anil Gupta - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Thanks Regards, Anil Gupta
