Re: [VOTE] Accept XTable into the ASF Incubator
+1 (binding) Best of luck! On Fri, Dec 15, 2023, 6:18 PM Jesus Camacho Rodriguez wrote: > Hi All, > > Following the discussion in the incubator mailing list [1], I am starting > this official vote for the XTable project. > > Here is the proposal - > https://cwiki.apache.org/confluence/display/INCUBATOR/XTable+Proposal > > Please cast your vote: > > [ ] +1, bring XTable into the Incubator > [ ] +0, I don't care either way > [ ] -1, do not bring XTable into the Incubator, because... > > This majority vote is open for at least 96 hours (due to the weekend). > > Only votes from Incubator PMC members are binding, but other votes are > welcome! > > Thanks, > Jesús > > [1] https://lists.apache.org/thread/rx9z8ffrf37qjhpkf1vp5rqg5lhht7jm >
Re: [DISCUSS] OneTable proposal
I appreciate the name update. That addresses my concern there. Thanks for the quick update! If only all namings I've been involved in were that quick :) On Wed, Dec 13, 2023, 11:49 AM Jesus Camacho Rodriguez wrote: > The package would be xtable. > As for the pronunciation, I was pronouncing it as "eks table"... But it's > not something that has been discussed, I assume we are leaving it to the > interpretation of the reader for the time being :) > > -Jesús > > > On Wed, Dec 13, 2023 at 10:54 AM Julian Hyde > wrote: > > > Pronounced “eks table” I presume, and not “cross table” or “times table”? > > The Java package prefix would be org.apache.xtable, not x_table. > > > > (It’s good to check. I’m still traumatized whenever I have to say > > “PostgreSQL” out loud.) > > > > Julian > > > > > On Dec 13, 2023, at 7:13 AM, Jean-Baptiste Onofré > > wrote: > > > > > > Hi Jesus > > > > > > Yes, we first have to trigger the vote to accept XTable into the > > > incubator. As soon as the vote pass (hopefully), we have to trigger > > > the name search. > > > > > > Regards > > > JB > > > > > >> On Wed, Dec 13, 2023 at 4:06 PM Jesus Camacho Rodriguez > > >> wrote: > > >> > > >> Thanks JB. Based on the guidelines described here [1], I was going to > > run > > >> the name search process for XTable after the project is accepted for > > >> incubation, but before we start to request resources. > > >> > > >> -Jesús > > >> > > >> [1] https://www.apache.org/foundation/marks/naming.html#startsearch > > >> > > >> On Wed, Dec 13, 2023 at 2:02 AM Jean-Baptiste Onofré > > > >> wrote: > > >> > > >>> Thanks Jesus > > >>> > > >>> XTable sounds good but we need a name search anyway to be sure it's > > >>> suitable. > > >>> > > >>> Regards > > >>> JB > > >>> > > >>> On Wed, Dec 13, 2023 at 4:30 AM Jesus Camacho Rodriguez > > >>> wrote: > > > > I've updated the proposal with the new name: XTable. You can review > it > > here: > > >>> > https://cwiki.apache.org/confluence/display/INCUBATOR/XTable+Proposal > > (please also see _Project Name_ subsection) > > > > We hope this change addresses the concern that was raised during > this > > discussion, helping to convey a message of neutrality to anyone > > >>> interested > > in contributing to the project. > > > > We look forward to hearing from you soon. If there are no further > > >>> concerns, > > we would love to move forward with the VOTE as soon as possible. > > > > -Jesús > > > > > > > > On Mon, Dec 11, 2023 at 10:09 PM Jesus Camacho Rodriguez < > > jcama...@apache.org> wrote: > > > > > Thanks Julian. I was mainly considering the code, but, as you > > >>> mentioned, > > > it's probably not the primary concern. The current proposal aligns > > with > > > your feedback: The project will go through the vote (and hopefully > be > > > accepted into the incubator) using the new name, so all the infra > and > > > project setup can be done (hopefully) only once. > > > > > > -Jesús > > > > > > On Mon, Dec 11, 2023 at 5:29 PM Julian Hyde < > jhyde.apa...@gmail.com> > > > wrote: > > > > > >> Much easier to change the name before incubation. It’s not so much > > >>> code > > >> as all the infrastructure (mailing lists, git repos, web servers, > > svn > > >> files, …) that goes along with a podling. It’s a lot of work for > > >>> INFRA and > > >> for the PPMC/champion. > > >> > > >> Also, branding. Calcite entered incubation as ‘Optiq’ and then > > >>> renamed, > > >> but not before it had appeared in a few conference talks; people > are > > >>> still > > >> asking me ‘What happened to Optiq?' > > >> > > >> Julian > > >> > > >> > > >>> On Dec 11, 2023, at 5:08 PM, Jesus Camacho Rodriguez < > > >> jcama...@apache.org> wrote: > > >>> > > >>> Thanks to everyone who expressed support and offered help. It's > > >>> great to > > >>> see that the project's mission resonates with so many different > > >>> people. > > >>> > > >>> Jacques, we acknowledge your concern about the project name. We > are > > >> working > > >>> on selecting a new name for ASF incubation that avoids confusion > > >>> with > > >> any > > >>> specific corporation or product in the space. Currently we are > > doing > > >> some > > >>> due diligence to minimize the risk of having to change it again > > >>> during > > >>> incubation; we'll update the proposal with the new name soon and > > >>> share > > >> it > > >>> in this thread. > > >>> > > >>> Regarding the name-changing process and your concerns about it, > > >>> we're > > >>> looking for advice based on past experiences. Specifically, we're > > >>> considering whether it's better to change the project's name > before > > >> pushing > > >>> the code to the ASF, or if it's more practical to push the code > to
Re: [DISCUSS] OneTable proposal
FYI, I'm super supportive of the spirit of this work. The goal of the project is a noble one that has real demand. Sorry if my initial message sounded dour! I just wanted to make sure people were going in eyes wide open and give this project the best chance for success. On Fri, Dec 8, 2023, 8:28 AM Jacques Nadeau wrote: > I've shared this feedback with Jesus prior to the proposal but would like > to do here as well. This project is trying to make multiple open source > projects work together. It would be nice to see representation from > multiple of those communities. I feel that true success of this project is > heavily influenced by its acceptance of multiple communities, not just > those hailing from one. > > The name is a problem in that that it suggests inappropriate ties with > both OneLake and OneHouse, commercial products in the same space backed by > two companies the initial ipmc hail from. Normally I would be fine with the > typical "find a new name during incubation" process but the > market this technology is within is filled with fud and vitriol between > the backers of the multiple open source projects and I think it would be > best if the incubating project name had a placeholder name as opposed to > something that suggests any ASF sponsorship of vendor technologies. I > cynically suspect that if this is accepted we would then see one or more > vendors start writing about how ASF is backing OneTable before the renaming > would occur. Let's keep corporate influence out of this project from the > start. > > On Mon, Dec 4, 2023, 11:25 AM Jesus Camacho Rodriguez > wrote: > >> Hi All, >> >> I would like to propose a new project to the ASF incubator - OneTable. >> >> OneTable[1] is an omni-directional converter for table formats that >> facilitates interoperability across data processing systems and query >> engines. Currently, OneTable supports widely adopted open-source table >> formats such as Apache Hudi, Apache Iceberg, and Delta Lake. >> >> Here is the proposal - >> https://cwiki.apache.org/confluence/display/INCUBATOR/OneTable+Proposal >> >> I would be the Champion of the project. I will mentor and help the project >> through the incubator with Hitesh Shah [hit...@apache.org], Stamatis >> Zampetakis [zabe...@apache.org], and Jean-Baptiste Onofré [ >> jbono...@apache.org]. >> >> We are looking forward to your feedback! >> >> Thanks, >> Jesús >> >> [1] https://github.com/onetable-io/onetable >> >
Re: [DISCUSS] OneTable proposal
I've shared this feedback with Jesus prior to the proposal but would like to do here as well. This project is trying to make multiple open source projects work together. It would be nice to see representation from multiple of those communities. I feel that true success of this project is heavily influenced by its acceptance of multiple communities, not just those hailing from one. The name is a problem in that that it suggests inappropriate ties with both OneLake and OneHouse, commercial products in the same space backed by two companies the initial ipmc hail from. Normally I would be fine with the typical "find a new name during incubation" process but the market this technology is within is filled with fud and vitriol between the backers of the multiple open source projects and I think it would be best if the incubating project name had a placeholder name as opposed to something that suggests any ASF sponsorship of vendor technologies. I cynically suspect that if this is accepted we would then see one or more vendors start writing about how ASF is backing OneTable before the renaming would occur. Let's keep corporate influence out of this project from the start. On Mon, Dec 4, 2023, 11:25 AM Jesus Camacho Rodriguez wrote: > Hi All, > > I would like to propose a new project to the ASF incubator - OneTable. > > OneTable[1] is an omni-directional converter for table formats that > facilitates interoperability across data processing systems and query > engines. Currently, OneTable supports widely adopted open-source table > formats such as Apache Hudi, Apache Iceberg, and Delta Lake. > > Here is the proposal - > https://cwiki.apache.org/confluence/display/INCUBATOR/OneTable+Proposal > > I would be the Champion of the project. I will mentor and help the project > through the incubator with Hitesh Shah [hit...@apache.org], Stamatis > Zampetakis [zabe...@apache.org], and Jean-Baptiste Onofré [ > jbono...@apache.org]. > > We are looking forward to your feedback! > > Thanks, > Jesús > > [1] https://github.com/onetable-io/onetable >
Re: [VOTE] Recommend Apache Iceberg graduation to top-level project resolution to the board
+1 (binding). Congrats On Sat, May 16, 2020 at 2:27 PM Dave Fisher wrote: > +1 (binding) > > Best Regards, > Dave > > > On May 15, 2020, at 5:39 PM, Ryan Blue wrote: > > > > Hi everyone, > > > > With the support of our mentors (as well as helpful ASF members), the > > Apache Iceberg community has voted to graduate to a top-level project. > > > > I propose a vote to recommend graduation for the Iceberg community to the > > board. Here is the proposed resolution: > > > > ``` > > Establish the Apache Iceberg Project > > > > WHEREAS, the Board of Directors deems it to be in the best interests of > > the Foundation and consistent with the Foundation's purpose to establish > > a Project Management Committee charged with the creation and maintenance > > of open-source software, for distribution at no charge to the public, > > related to managing huge analytic datasets using a standard at-rest > > table format that is designed for high performance and ease of use.. > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee > > (PMC), to be known as the "Apache Iceberg Project", be and hereby is > > established pursuant to Bylaws of the Foundation; and be it further > > > > RESOLVED, that the Apache Iceberg Project be and hereby is responsible > > for the creation and maintenance of software related to managing huge > > analytic datasets using a standard at-rest table format that is designed > > for high performance and ease of use; and be it further > > > > RESOLVED, that the office of "Vice President, Apache Iceberg" be and > > hereby is created, the person holding such office to serve at the > > direction of the Board of Directors as the chair of the Apache Iceberg > > Project, and to have primary responsibility for management of the > > projects within the scope of responsibility of the Apache Iceberg > > Project; and be it further > > > > RESOLVED, that the persons listed immediately below be and hereby are > > appointed to serve as the initial members of the Apache Iceberg Project: > > > > * Anton Okolnychyi > > * Carl Steinbach > > * Daniel C. Weeks > > * James R. Taylor > > * Julien Le Dem > > * Owen O'Malley > > * Parth Brahmbhatt > > * Ratandeep Ratti > > * Ryan Blue > > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ryan Blue be appointed to > > the office of Vice President, Apache Iceberg, to serve in accordance > > with and subject to the direction of the Board of Directors and the > > Bylaws of the Foundation until death, resignation, retirement, removal > > or disqualification, or until a successor is appointed; and be it > > further > > > > RESOLVED, that the Apache Iceberg Project be and hereby is tasked with > > the migration and rationalization of the Apache Incubator Iceberg > > podling; and be it further > > > > RESOLVED, that all responsibilities pertaining to the Apache Incubator > > Iceberg podling encumbered upon the Apache Incubator PMC are hereafter > > discharged. > > ``` > > > > The community vote passed with 19 +1 votes: > > > https://lists.apache.org/thread.html/r9081df0181768f26490f5a85aed7b5a111a82a741764eb3a0e99621d%40%3Cdev.iceberg.apache.org%3E > > > > We also addressed concerns on the IPMC thread, which you can read here: > > > https://lists.apache.org/thread.html/r3e5795d959feb0a19b233aeaf1121a1d97fd473f5e9b14227de41c54%40%3Cgeneral.incubator.apache.org%3E > > > > Please vote on whether to recommend graduation for the Apache Iceberg > > community to the board. > > > > [ ] +1 Apache Iceberg should graduate > > [ ] +0 > > [ ] -1 Apache Iceberg should not graduate because . . . > > > > The vote will be open for at least 72 hours. > > > > -- > > Ryan Blue > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache Iceberg 0.7.0-incubating RC4
+1 (binding) Downloaded, reviewed licenses. Spot check for bad licenses. Built from source + tests. Nice job on the first release guys! On Tue, Oct 22, 2019 at 4:05 PM James Taylor wrote: > +1 (binding). > > Successfully downloaded, verified license, verified checksum, verified > signature, built from source, and ran unit tests. > Minor nit (ok to fix in next release IMHO): Copyright in NOTICE for Iceberg > should read 2017-2019 > > > > On Tue, Oct 22, 2019 at 3:21 PM Ryan Blue wrote: > > > Hi everyone, > > > > I propose the following RC to be released as official Apache Iceberg > > 0.7.0-incubating release. > > > > This candidate has passed a PPMC vote. The result thread is here: > > * > > > > > https://lists.apache.org/thread.html/fe76494f9feab454837bc2dc540cd9e59d55dac3f7e0b5b335de7725@ > > > > > > The commit id is 9c81babac65351f7aa21dd878f01c5c81ae304af > > * This corresponds to the tag: apache-iceberg-0.7.0-incubating-rc4 > > * > > > > > https://github.com/apache/incubator-iceberg/tree/apache-iceberg-0.7.0-incubating-rc4 > > * > > > > > https://github.com/apache/incubator-iceberg/tree/9c81babac65351f7aa21dd878f01c5c81ae304af > > > > The release tarball, signature, and checksums are here: > > * > > > > > https://dist.apache.org/repos/dist/dev/incubator/iceberg/apache-iceberg-0.7.0-incubating-rc4/ > > > > You can find the KEYS file here: > > * https://dist.apache.org/repos/dist/dev/incubator/iceberg/KEYS > > > > This release includes convenience binary artifacts that are staged in > > Nexus. The Maven repository URL is: > > * > > > https://repository.apache.org/content/repositories/orgapacheiceberg-1004/ > > > > The convenience binaries include a Spark runtime Jar with shaded > > dependencies. The LICENSE and NOTICE content for that Jar are viewable in > > github as well as in the Jar: > > > > > https://github.com/apache/incubator-iceberg/tree/apache-iceberg-0.7.0-incubating-rc4/runtime > > > > To build and test, run `./gradlew build`. You can also test by adding the > > iceberg-spark-runtime Jar to the jars folder of Spark 2.4. > > > > This is the first Apache Iceberg release. > > > > Please download, verify, and test; then vote in the next 72 hours. > > > > [ ] +1 Release this as Apache Iceberg 0.7.0-incubating > > [ ] +0 > > [ ] -1 Do not release this because... > > > > -- > > Ryan Blue > > >
Re: [IP CLEARANCE] Arrow Gandiva library
+1 On Tue, Sep 25, 2018, 3:00 PM Wes McKinney wrote: > hi folks, > > I missed that the software grant for this had not yet been filed with > the ASF secretary, but this is done now. I have updated the IP > Clearance document and will leave this vote open for another 72 hours > from now. > > Thank you, > Wes > On Mon, Sep 24, 2018 at 12:26 PM Ryan Blue > wrote: > > > > +1 > > > > On Mon, Sep 24, 2018 at 9:24 AM Matt Sicker wrote: > > > > > +1 > > > > > > On Fri, 21 Sep 2018 at 14:09, Wes McKinney > wrote: > > > > > > > Apache Arrow is receiving a donation of the Gandiva library, an > > > > LLVM-based analytical expression compiler framework [1] > > > > > > > > Please vote to approve this contribution. > > > > > > > > This is a lazy consensus majority vote, per the IP clearance process > > > > [2], open for at least 72 hours. > > > > > > > > Wes > > > > > > > > [1]: http://incubator.apache.org/ip-clearance/arrow-gandiva.html > > > > [2] http://incubator.apache.org/ip-clearance/ > > > > > > > > - > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > -- > > > Matt Sicker > > > > > > > > > -- > > Ryan Blue > > Software Engineer > > Netflix > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Edit Access to Wiki
I just realized that I've either lost my account (or never had one) for editing the Wiki. Can I get edit access? Username: jacquesnadeau thanks! Jacques
Re: [VOTE] Heron to enter Apache Incubator
incubator.apache.org > * comm...@heron.incubator.apache.org > * u...@heron.incubator.apache.org > > == Subversion Directory == > > Git is the preferred source control system: git://git.apache.org/heron > > == Issue Tracking == > > JIRA: Heron (HERON) > > == Initial Committers == > > * Andrew Jorgensen (andrew at andrewjorgensen dot com) > * Ashvin Agrawal (ashvin at apache dot org)* > * Avrilia Floratou (avrilia dot floratou at gmail dot com) > * Bill Graham (billgraham at apache dot org)* > * Brian Hatfield (bmhatfield at gmail dot com) > * Chris Kellogg (cckellogg at gmail dot com) > * Huijun Wu (huijun dot wu dot 2010 at gmail dot com) > * Karthik Ramasamy (karthik at gmail dot com) > * Maosong Fu (maosongfu at gmail dot com) > * Neng Lu(freeneng at gmail dot com) > * Runhang Li (obj dot runhang at gmail dot com) > * Sanjeev Kulkarni (sanjeevrk at gmail dot com) > * Supun Kamburugamuve (supun at apache dot org)* > * Thomas Sun (tom dot ssf at gmail dot com) > * Yaliang Wang (yaliang dot w dot wang at ieee dot org) > > == Affiliations == > > * Andrew Jorgensen (Google) > * Ashvin Agrawal (Microsoft) > * Avrilia Floratou (Microsoft) > * Bill Graham (Twitter) > * Brian Hatfield (Google) > * Chris Kellogg (Twitter) > * Huijun Wu (Twitter) > * Karthik Ramasamy (Streamlio) > * Maosong Fu (Twitter) > * Neng Lu (Twitter) > * Runhang Li (Twitter) > * Sanjeev Kulkarni (Streamlio) > * Supun Kamburugamuve (Indiana University) > * Thomas Sun (Twitter) > * Yaliang Wang (Twitter) > > = Sponsors = > > == Champion == > > * Julien Le Dem (julien at apache dot org) > > == Nominated Mentors == > > * Jake Farrell (jfarrell at apache dot org) > * Jacques Nadeau (jacques at apache dot org) > * Julien Le Dem (julien at apache dot org) > * P. Taylor Goetz (ptgoetz at apache dot org) > > == Sponsoring Entity == > > The Apache Incubator > > == Footnotes == > > * 1 - Papers detailing Heron are available at > http://dl.acm.org/citation.cfm?id=2742788 and > http://sites.computer.org/debull/A15dec/p15.pdf. > * 2 - http://home.apache.org/phonebook.html?uid=billgraham > * 3 - http://home.apache.org/phonebook.html?uid=ashvin > * 4 - http://home.apache.org/phonebook.html?uid=supun -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Superset Proposal for Apache Incubator
+1 binding On Apr 27, 2017 1:35 PM, "Jitendra Pandey" wrote: > Re-affirming. +1 (binding) > > On 4/27/17, 1:24 PM, "Ashutosh Chauhan" > wrote: > > Re-affirming my vote as well: > > +1 (binding) > > On Thu, Apr 27, 2017 at 10:45 AM, Julian Hyde > wrote: > > > Re-affriming my vote: > > > > +1 (binding) > > > > > On Apr 26, 2017, at 11:12 PM, Jeff Feng > wrote: > > > > > > Hello everyone, > > > > > > Thank you for checking out our proposal on Superset and for your > > > consideration for the Apache Incubator. So far, I believe we have > 8 > > > binding votes and 2 non-binding votes. > > > > > > As Taylor mentioned earlier, we made a minor update to the wording > in the > > > "Source and Intellectual Property Submission Plan" section based > on a > > > suggestion by John Ament. The update was to help confirm the > previously > > > unstated assumption that we will submit an SGA. I have copied the > > updated > > > proposal from the wiki to the email below and highlighted (in > yellow) the > > > new sentence below in the document. > > > > > > Folks on the cc line who have already voted, please let us know if > the > > > change impacts your vote. > > > > > > Thank you all, > > > Jeff > > > > > > > > > > > > = Superset = > > > > > > == Abstract == > > > Superset is an enterprise-ready web application for data > exploration, > > data > > > visualization and dashboarding. > > > > > > == Proposal == > > > Superset is business intelligence (BI) software that helps modern > > > organizations visualize and interact with their data. Superset > enables > > > users explore data from a variety of databases, assemble beautiful > > > dashboards and share their findings. Superset works neatly with > all > > modern > > > SQL-speaking databases, and integrates with Druid.io to provide > > real-time, > > > interactive, blazing fast data access to large datasets. > > > > > > == Background == > > > Data is mission critical. To succeed in this era, organizations > need to > > > provide low-friction, intuitive and interactive access to data. It > is > > > paramount for knowledge workers to be capable of answering their > own > > > questions by querying, exploring and visualizing data. > > > > > > The entire business intelligence industry has pivoted from a model > of > > > centralized top-down platforms driven by IT organizations to > self-service > > > analytics and agile workflows by any user. This shift unblocks > > centralized > > > service bottlenecks for creating data visualizations while also > creating > > an > > > environment that is iterative and fast-moving. This means that > business > > > intelligence software must also be easy and delightful to use. > > > Self-service analytics doesn’t mean that admin and governance > features > > are > > > not needed. > > > Modern BI tools provide fine-grain access controls and auditing > > > capabilities to understand how data is being used. Superset is a > > solution > > > that delivers on all of these vectors. > > > > > > The technology stack is also constantly morphing - vendors are > struggling > > > to provide cheap, quick and easy solutions to access data. > Business > > > intelligence users are finding existing solutions lacking as these > > software > > > products either disregard or react slowly to recent game-changing > > > technologies like Druid.io, PrestoDB, Apache Drill, Apache Kylin, > d3.js, > > > React.js and iPython’s Jupyter for instance. > > > > > > == Rationale == > > > Business intelligence is more relevant today than at any other > point in > > > history. Organizations are currently very limited in options for > open > > > source data visualization solutions, especially solutions that are > both > > > self-service and enterprise-ready. Every company informing their > > decisions > > > with data needs a BI tool. > > > > > > We believe that Superset will be a strong compliment to existing > Apache > > > Software Foundation technologies by offering scalable user > interactions > > to > > > distributed storage and computation solutions. Users will often > find > > that > > > Superset can act as a catalyst for tooling that can visualize the > > byproduct > > > of data and computation infrastructure. > > > > > > Superset has many key design elements that help fill a gap in > current > > > solutions for organizations: > > > * Easy, low friction access to data through a simple, web-based > data > > > exploration interface. Composing charts and dashboards are > intuitive. > > > Eliminating the need to write code or SQL empowers anyone to use > it. > > > * Ac
Re: [RESTART] [VOTE] Graduate Apache Beam
+1 (binding) Good luck guys! On Mon, Dec 5, 2016 at 4:02 PM, Hugo Louro wrote: > +1 (non-binding) > > On Mon, Dec 5, 2016 at 3:56 PM, John D. Ament > wrote: > > > +1 > > > > On Mon, Dec 5, 2016 at 6:31 PM Davor Bonaci wrote: > > > > > Hi everyone, > > > Please vote on the draft resolution proposed by the Apache Beam PPMC > > below, > > > which establishes Apache Beam as a new top-level project at the Apache > > > Software Foundation, as follows: > > > > > > [ ] +1, Graduate Apache Beam from the Incubator. > > > [ ] +0, Don't care. > > > [ ] -1, Don't graduate Apache Beam from the Incubator because... > > > > > > Please note that this is a restarted vote, per John's request, to > clarify > > > the alternatives. The old voting thread is archived [1]. > > > > > > Before voting, please see the full text of the draft resolution below > and > > > the corresponding discussion thread [2], and vote only after you feel > > ready > > > to do so. The vote will be open for at least 72 hours. This is a > > procedural > > > vote [3]; it is adopted by a simple majority of qualified votes (with > no > > > minimum). > > > > > > If approved by the Apache Incubator, the proposed resolution will be > > > submitted to the Board of Directors for their consideration. > > > > > > Thank you! > > > > > > Davor > > > > > > [1] > > > > > > https://lists.apache.org/thread.html/a8e9cecfe93f0e464cc7c1774d2761 > > ca14326df1101b7670ca8b1dc3@%3Cgeneral.incubator.apache.org%3E > > > [2] > > > > > > https://lists.apache.org/thread.html/b9c1071b35558846836814575ada3c > > dca61c72dc1e672ab994a9c936@%3Cgeneral.incubator.apache.org%3E > > > [3] http://apache.org/foundation/voting.html > > > > > > The full-text of the draft resolution proposed by the Apache Beam PPMC: > > > > > > X. Establish the Apache Beam Project > > > > > >WHEREAS, the Board of Directors deems it to be in the best > > >interests of the Foundation and consistent with the > > >Foundation's purpose to establish a Project Management > > >Committee charged with the creation and maintenance of > > >open-source software, for distribution at no charge to > > >the public, related to a unified programming model for both > > >batch and streaming data processing, enabling efficient > > >execution across diverse distributed execution engines > > >and providing extensibility points for connecting to different > > >technologies and user communities. > > > > > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management > > >Committee (PMC), to be known as the "Apache Beam Project", > > >be and hereby is established pursuant to Bylaws of the > > >Foundation; and be it further > > > > > >RESOLVED, that the Apache Beam Project be and hereby is > > >responsible for the creation and maintenance of software > > >related to a unified programming model for both batch and > > >streaming data processing, enabling efficient execution across > > >diverse distributed execution engines and providing > extensibility > > >points for connecting to different technologies and user > > >communities; and be it further > > > > > >RESOLVED, that the office of "Vice President, Apache Beam" be > > >and hereby is created, the person holding such office to > > >serve at the direction of the Board of Directors as the chair > > >of the Apache Beam Project, and to have primary responsibility > > >for management of the projects within the scope of > > >responsibility of the Apache Beam Project; and be it further > > > > > >RESOLVED, that the persons listed immediately below be and > > >hereby are appointed to serve as the initial members of the > > >Apache Beam Project: > > > > > > * Tyler Akidau > > > * Davor Bonaci > > > * Robert Bradshaw > > > * Ben Chambers > > > * Luke Cwik > > > * Stephan Ewen > > > * Dan Halperin > > > * Kenneth Knowles > > > * Aljoscha Krettek > > > * Maximilian Michels > > > * Jean-Baptiste Onofré > > > * Frances Perry > > > * Amit Sela > > > * Josh Wills > > > > > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Davor Bonaci > > >be appointed to the office of Vice President, Apache Beam, to > > >serve in accordance with and subject to the direction of the > > >Board of Directors and the Bylaws of the Foundation until > > >death, resignation, retirement, removal or disqualification, > > >or until a successor is appointed; and be it further > > > > > >RESOLVED, that the initial Apache Beam PMC be and hereby is > > >tasked with the creation of a set of bylaws intended to > > >encourage open development and increased participation in the > > >
Re: [VOTE] Bring Griffin to Apache Incubator
+1 (binding) On Thu, Dec 1, 2016 at 8:47 AM, Andrew Purtell wrote: > +1 (binding) > > > On Dec 1, 2016, at 8:35 AM, Felix Cheung wrote: > > > > +1 > > > > On Wed, Nov 30, 2016 at 10:40 PM Henry Saputra > > wrote: > > > >> Hi All, > >> > >> As the champion for Griffin, I would like to start VOTE to bring the > >> project as Apache incubator podling. > >> > >> Here is the direct quote from the abstract: > >> > >> " > >> Griffin is a Data Quality Service platform built on Apache Hadoop and > >> Apache Spark. It provides a framework process for defining data > >> quality model, executing data quality measurement, automating data > >> profiling and validation, as well as a unified data quality > >> visualization across multiple data systems. It tries to address the > >> data quality challenges in big data and streaming context. > >> " > >> > >> Please cast your vote: > >> > >> [ ] +1, bring Griffin into Incubator > >> [ ] +0, I don't care either way, > >> [ ] -1, do not bring Griffin into Incubator, because... > >> > >> This vote will be open at least for 72 hours and only votes from the > >> Incubator PMC are binding. > >> > >> The VOTE will end 12/5 9am PST to pass through weekend. > >> > >> > >> Here is the link to the proposal: > >> > >> https://wiki.apache.org/incubator/GriffinProposal > >> > >> I have copied the proposal below for easy access > >> > >> > >> Thanks, > >> > >> - Henry > >> > >> > >> > >> Griffin Proposal > >> > >> Abstract > >> > >> Griffin is a Data Quality Service platform built on Apache Hadoop and > >> Apache Spark. It provides a framework process for defining data > >> quality model, executing data quality measurement, automating data > >> profiling and validation, as well as a unified data quality > >> visualization across multiple data systems. It tries to address the > >> data quality challenges in big data and streaming context. > >> > >> Proposal > >> > >> Griffin is a open source Data Quality solution for distributed data > >> systems at any scale in both streaming or batch data context. When > >> people use open source products (e.g. Apache Hadoop, Apache Spark, > >> Apache Kafka, Apache Storm), they always need a data quality service > >> to build his/her confidence on data quality processed by those > >> platforms. Griffin creates a unified process to define and construct > >> data quality measurement pipeline across multiple data systems to > >> provide: > >> > >> Automatic quality validation of the data > >> Data profiling and anomaly detection > >> Data quality lineage from upstream to downstream data systems. > >> Data quality health monitoring visualization > >> Shared infrastructure resource management > >> > >> Overview of Griffin > >> > >> Griffin has been deployed in production at eBay serving major data > >> systems, it takes a platform approach to provide generic features to > >> solve common data quality validation pain points. Firstly, user can > >> register the data asset which user wants to do data quality check. The > >> data asset can be batch data in RDBMS (e.g.Teradata), Apache Hadoop > >> system or near real-time streaming data from Apache Kafka, Apache > >> Storm and other real time data platforms. Secondly, user can create > >> data quality model to define the data quality rule and metadata. > >> Thirdly, the model or rule will be executed automatically (by the > >> model engine) to get the sample data quality validation results in a > >> few seconds for streaming data. Finally, user can analyze the data > >> quality results through built-in visualization tool to take actions. > >> > >> Griffin includes: > >> > >> Data Quality Model Engine > >> > >> Griffin is model driven solution, user can choose various data quality > >> dimension to execute his/her data quality validation based on selected > >> target data-set or source data-set ( as the golden reference data). It > >> has a corresponding library supporting it in back-end for the > >> following measurement: > >> > >> Accuracy - Does data reflect the real-world objects or a verifiable > source > >> Completeness - Is all necessary data present > >> Validity - Are all data values within the data domains specified by the > >> business > >> Timeliness - Is the data available at the time needed > >> Anomaly detection - Pre-built algorithm functions for the > >> identification of items, events or observations which do not conform > >> to an expected pattern or other items in a dataset > >> Data Profiling - Apply statistical analysis and assessment of data > >> values within a dataset for consistency, uniqueness and logic. > >> > >> Data Collection Layer > >> > >> We support two kinds of data sources, batch data and real time data. > >> > >> For batch mode, we can collect data source from Apache Hadoop based > >> platform by various data connectors. > >> > >> For real time mode, we can connect with messaging system like Kafka to > >> near real time analysis. > >> > >> Data Process and Storage Layer > >>
Re: [RESULT][VOTE] Apache CarbonData 0.2.0-incubating release
I didn't see the last +1 so I reviewed and also gave you a +1. Guess that is not needed now :P On Sat, Nov 19, 2016 at 5:33 AM, Liang Chen wrote: > Hi > > Finally, this vote passed with the following result: > > +1 (binding) : John D. Ament,Henry Saputra,Uma Gangumalla,Jean-Baptiste > Onofré > > Thanks all for your vote. > > Regards > Liang > > > Liang Chen wrote > > Hi all > > > > Finally, this vote passed with the following result: > > > > +1 (binding) : Henry Saputra,Uma Gangumalla,Jean-Baptiste Onofré > > > > Thanks all for your vote. > > > > > > Regards > > Liang > > > > > > -- > View this message in context: http://apache-incubator- > general.996316.n3.nabble.com/RESULT-VOTE-Apache-CarbonData- > 0-2-0-incubating-release-tp52527p52536.html > Sent from the Apache Incubator - General mailing list archive at > Nabble.com. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Apache CarbonData 0.2.0-incubating release
Built, ran tests, checked signatures. Agree that next build shouldn't pass without clarification on build instructions. For this build: +1 (binding) On Sat, Nov 19, 2016 at 5:33 AM, Liang Chen wrote: > Hi > > Thanks John. > Definitely, we would provide the more clear build instructions. > > Regards > Liang > > > John D. Ament-2 wrote > > I'm changing my vote to +1 since I'm able to build from source after > > installing thrift. > > > > Going through this did point out one issue - the Thrift TLP does not > > publish valid releases. I've pinged them separately. > > > > John > > > > On Tue, Nov 15, 2016 at 6:50 PM John D. Ament < > > > johndament@ > > > > wrote: > > > >> Hi sorry but I'm -1 since I cannot build it from source. Would be ok if > >> it compiles and some tests fail, but this won't even compile. > >> > >> Please note - -1's are not veto's if you get enough +1's to outweigh, it > >> will still pass. Though it would be good to if you re-roll the release > >> to > >> fix this build issue. > >> > >> John > >> > >> > >> On Tue, Nov 15, 2016 at 9:46 AM Liang Chen < > > > chenliang6136@ > > > > > >> wrote: > >> > >> Hi John D. Ament and Henry > >> > >> Gentle reminder! > >> Could you please check again? please feel free to let me know if need to > >> provide more information. > >> > >> BTW,building document at: > >> > >> https://cwiki.apache.org/confluence/display/CARBONDATA/ > Building+CarbonData+And+IDE+Configuration > >> > >> Regards > >> Liang > >> > >> > >> > >> > >> -- > >> View this message in context: > >> http://apache-incubator-general.996316.n3.nabble.com/ > VOTE-Apache-CarbonData-0-2-0-incubating-release-tp52465p52490.html > >> Sent from the Apache Incubator - General mailing list archive at > >> Nabble.com. > >> > >> - > >> To unsubscribe, e-mail: > > > general-unsubscribe@.apache > > >> For additional commands, e-mail: > > > general-help@.apache > > >> > >> > > > > > > -- > View this message in context: http://apache-incubator- > general.996316.n3.nabble.com/VOTE-Apache-CarbonData-0-2-0- > incubating-release-tp52465p52535.html > Sent from the Apache Incubator - General mailing list archive at > Nabble.com. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Accept CarbonData into the Apache Incubator
+1 (binding) On Wed, May 25, 2016 at 4:04 PM, John D. Ament wrote: > +1 > > On Wed, May 25, 2016 at 4:41 PM Jean-Baptiste Onofré > wrote: > > > Hi all, > > > > following the discussion thread, I'm now calling a vote to accept > > CarbonData into the Incubator. > > > > [ ] +1 Accept CarbonData into the Apache Incubator > > [ ] +0 Abstain > > [ ] -1 Do not accept CarbonData into the Apache Incubator, because ... > > > > This vote is open for 72 hours. > > > > The proposal follows, you can also access the wiki page: > > https://wiki.apache.org/incubator/CarbonDataProposal > > > > Thanks ! > > Regards > > JB > > > > = Apache CarbonData = > > > > == Abstract == > > > > Apache CarbonData is a new Apache Hadoop native file format for faster > > interactive > > query using advanced columnar storage, index, compression and encoding > > techniques > > to improve computing efficiency, in turn it will help speedup queries an > > order of > > magnitude faster over PetaBytes of data. > > > > CarbonData github address: https://github.com/HuaweiBigData/carbondata > > > > == Background == > > > > Huawei is an ICT solution provider, we are committed to enhancing > > customer experiences for telecom carriers, enterprises, and consumers on > > big data, In order to satisfy the following customer requirements, we > > created a new Hadoop native file format: > > > > * Support interactive OLAP-style query over big data in seconds. > > * Support fast query on individual record which require touching all > > fields. > > * Fast data loading speed and support incremental load in period of > > minutes. > > * Support HDFS so that customer can leverage existing Hadoop cluster. > > * Support time based data retention. > > > > Based on these requirements, we investigated existing file formats in > > the Hadoop eco-system, but we could not find a suitable solution that > > satisfying requirements all at the same time, so we start designing > > CarbonData. > > > > == Rationale == > > > > CarbonData contains multiple modules, which are classified into two > > categories: > > > > 1. CarbonData File Format: which contains core implementation for file > > format such as columnar,index,dictionary,encoding+compression,API for > > reading/writing etc. > > 2. CarbonData integration with big data processing framework such as > > Apache Spark, Apache Hive etc. Apache Beam is also planned to abstract > > the execution runtime. > > > > === CarbonData File Format === > > > > CarbonData file format is a columnar store in HDFS, it has many features > > that a modern columnar format has, such as splittable, compression > > schema ,complex data type etc. And CarbonData has following unique > > features: > > > > Indexing > > > > In order to support fast interactive query, CarbonData leverage indexing > > technology to reduce I/O scans. CarbonData files stores data along with > > index, the index is not stored separately but the CarbonData file itself > > contains the index. In current implementation, CarbonData supports 3 > > types of indexing: > > > > 1. Multi-dimensional Key (B+ Tree index) > > The Data block are written in sequence to the disk and within each > > data blocks each column block is written in sequence. Finally, the > > metadata block for the file is written with information about byte > > positions of each block in the file, Min-Max statistics index and the > > start and end MDK of each data block. Since, the entire data in the file > > is in sorted order, the start and end MDK of each data block can be used > > to construct a B+Tree and the file can be logically represented as a > > B+Tree with the data blocks as leaf nodes (on disk) and the remaining > > non-leaf nodes in memory. > > 2. Inverted index > > Inverted index is widely used in search engine. By using this index, > > it helps processing/query engine to do filtering inside one HDFS block. > > Furthermore, query acceleration for count distinct like operation is > > made possible when combining bitmap and inverted index in query time. > > 3. MinMax index > > For all columns, minmax index is created so that processing/query > > engine can skip scan that is not required. > > > > Global Dictionary > > > > Besides I/O reduction, CarbonData accelerates computation by using > > global dictionary, which enables processing/query engines to perform all > > processing on encoded data without having to convert the data (Late > > Materialization). We have observed dramatic performance improvement for > > OLAP analytic scenario where table contains many columns in string data > > type. The data is converted back to the user readable form just before > > processing/query engine returning results to user. > > > > Column Group > > > > Sometimes users want to perform processing/query on multi-columns in one > > table, for example, performing scan for individual record in > > troubleshooting scenario. In this case, row format is more efficient
Re: [VOTE] Accept Airflow into the Incubator
+1 (binding) On Fri, Mar 25, 2016 at 5:57 AM, Jeremiah Lowin wrote: > +1 (non-binding) > > Jeremiah > > > > On Mar 25, 2016, at 8:26 AM, Suresh Marru wrote: > > > > + 1 (binding). > > > > Suresh > > > >> On Mar 24, 2016, at 11:00 PM, Siddharth Anand > wrote: > >> > >> Following the discussion earlier: > >> https://s.apache.org/AirflowDiscussion > >> > >> I would like to call a VOTE for accepting Airflow as a new incubator > project. > >> > >> The proposal is available at: > https://wiki.apache.org/incubator/AirflowProposal > >> > >> The proposal is also included at the bottom of this email. > >> > >> Vote is open until at least Tues, 29 March 2016, 23:59:00 PDT > >> [ ] +1 accept Airflow into the Apache Incubator > >> [ ] ±0 > >> [ ] -1 because... > >> > >> +1 (non-binding) > >> > >> Thanks, > >> -s (Sid) > >> > >> > >> == Abstract == > >> > >> Airflow is a workflow automation and scheduling system that can be > >> used to author and manage data pipelines. > >> > >> == Proposal == > >> > >> Airflow provides a system for authoring and managing workflows a.k.a. > >> data pipelines a.k.a. DAGs (Directed Acyclic Graphs). The developer > >> authors DAGs in Python using an Airflow-provided framework. He/She > >> then executes the DAG using Airflow’s scheduler or registers the DAG > >> for event-based execution. A web-based UI provides the developer with > >> a range of options for managing and viewing his/her data pipelines. > >> Background > >> > >> Airflow was developed at Airbnb to enable easier authorship and > >> management of DAGs than were possible with existing solutions such as > >> Oozie and Azkaban. For starters, both Oozie and Azkaban rely on one or > >> more XML or property files to be bundled together to define a > >> workflow. This separation of code and config can present a challenge > >> to understanding the DAG - in Azkaban, a DAG’s structure is reflected > >> by its file system tree and one can find himself/herself traversing > >> the file system when inspecting or changing the structure of the DAG. > >> Airflow workflows, on the other hand, are simply and elegantly defined > >> in Python code, often a single file. Airflow merges the powerful > >> Web-based management aspects of projects like Azkaban and Oozie with > >> the simplicity and elegance of defining workflows in Python. Airflow, > >> less than a year old in terms of its Open Source launch, is currently > >> used in production environments in more than 30 companies and boasts > >> an active contributor list of more than 100 developers, the vast > >> majority of which (>95%) are outside of Airbnb. > >> > >> We would like to share it with the ASF and begin developing a > >> community of developers and users within Apache. > >> > >> == Rationale == > >> > >> Many organizations (>30) already benefit from running Airflow to > >> manage data pipelines. Our 100+ contributors continue to provide > >> integrations with 3rd party systems through the implementation of new > >> hooks and operators, both of which are used in defining the tasks that > >> compose workflows. > >> > >> == Current Status == > >> > >> === Meritocracy === > >> > >> Our intent with this incubator proposal is to start building a diverse > >> developer community around Airflow following the Apache meritocracy > >> model. Since Airflow was open-sourced in mid-2015, we have had fast > >> adoption and contributions by multiple organizations the world over. > >> We plan to continue to support new contributors and we will work to > >> actively promote those who contribute significantly to the project to > >> committers. > >> > >> === Community === > >> > >> Airflow is currently being used in over 30 companies. We hope to > >> extend our contributor base significantly and invite all those who are > >> interested in building large-scale distributed systems to participate. > >> > >> === Core Developers === > >> > >> Airflow is currently being developed by four engineers: Maxime > >> Beauchemin, Siddharth Anand, Bolke de Bruin, and Chris Riccomini. > >> Chris is a member of the Apache Samza PMC and a contributor to various > >> Apache projects, including Apache Kafka and Apache YARN. Maxime, > >> Siddharth, and Bolke have contributed to Airflow. > >> > >> === Alignment === > >> The ASF is the natural choice to host the Airflow project as its goal > >> of encouraging community-driven open-source projects fits with our > >> vision for Airflow. > >> > >> == Known Risks == > >> > >> === Orphaned Products === > >> > >> The core developers plan to work part time on the project. There is > >> very little risk of Airflow being abandoned as all of our companies > >> rely on it. > >> > >> === Inexperience with Open Source === > >> > >> All of the core developers have experience with open source > >> development. Chris is a member of the Apache Samza PMC and a > >> contributor to various Apache projects, including Apache Kafka and > >> Apache YARN. Bolke is contributor on multiple open
Re: [VOTE] Accept Mnemonic into the Apache Incubator
+1 (binding) thanks, Jacques On Mon, Feb 29, 2016 at 9:37 AM, Patrick Hunt wrote: > Hi folks, > > OK the discussion is now completed. Please VOTE to accept Mnemonic > into the Apache Incubator. I’ll leave the VOTE open for at least > the next 72 hours, with hopes to close it Thursday the 3rd of > March, 2016 at 10am PT. > https://wiki.apache.org/incubator/MnemonicProposal > > [ ] +1 Accept Mnemonic as an Apache Incubator podling. > [ ] +0 Abstain. > [ ] -1 Don’t accept Mnemonic as an Apache Incubator podling because.. > > Of course, I am +1 on this. Please note VOTEs from Incubator PMC > members are binding but all are welcome to VOTE! > > Regards, > > Patrick > > > = Mnemonic Proposal = > === Abstract === > Mnemonic is a Java based non-volatile memory library for in-place > structured data processing and computing. It is a solution for generic > object and block persistence on heterogeneous block and > byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD, > and cloud network storage. > > === Proposal === > Mnemonic is a structured data persistence in-memory in-place library > for Java-based applications and frameworks. It provides unified > interfaces for data manipulation on heterogeneous > block/byte-addressable devices, such as DRAM, persistent memory, NVMe, > SSD, and cloud network devices. > > The design motivation for this project is to create a non-volatile > programming paradigm for in-memory data object persistence, in-memory > data objects caching, and JNI-less IPC. > Mnemonic simplifies the usage of data object caching, persistence, and > JNI-less IPC for massive object oriented structural datasets. > > Mnemonic defines Non-Volatile Java objects that store data fields in > persistent memory and storage. During the program runtime, only > methods and volatile fields are instantiated in Java heap, > Non-Volatile data fields are directly accessed via GET/SET operation > to and from persistent memory and storage. Mnemonic avoids SerDes and > significantly reduces amount of garbage in Java heap. > > Major features of Mnemonic: > * Provides an abstract level of viewpoint to utilize heterogeneous > block/byte-addressable device as a whole (e.g., DRAM, persistent > memory, NVMe, SSD, HD, cloud network Storage). > > * Provides seamless support object oriented design and programming > without adding burden to transfer object data to different form. > > * Avoids the object data serialization/de-serialization for data > retrieval, caching and storage. > > * Reduces the consumption of on-heap memory and in turn to reduce and > stabilize Java Garbage Collection (GC) pauses for latency sensitive > applications. > > * Overcomes current limitations of Java GC to manage much larger > memory resources for massive dataset processing and computing. > > * Supports the migration data usage model from traditional NVMe/SSD/HD > to non-volatile memory with ease. > > * Uses lazy loading mechanism to avoid unnecessary memory consumption > if some data does not need to use for computing immediately. > > * Bypasses JNI call for the interaction between Java runtime > application and its native code. > > * Provides an allocation aware auto-reclaim mechanism to prevent > external memory resource leaking. > > > === Background === > Big Data and Cloud applications increasingly require both high > throughput and low latency processing. Java-based applications > targeting the Big Data and Cloud space should be tuned for better > throughput, lower latency, and more predictable response time. > Typically, there are some issues that impact BigData applications' > performance and scalability: > > 1) The Complexity of Data Transformation/Organization: In most cases, > during data processing, applications use their own complicated data > caching mechanism for SerDes data objects, spilling to different > storage and eviction large amount of data. Some data objects contains > complex values and structure that will make it much more difficulty > for data organization. To load and then parse/decode its datasets from > storage consumes high system resource and computation power. > > 2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes > Frequent Long GC Pauses: Big Data computing/syntax generates large > amount of temporary objects during processing, e.g. lambda, SerDes, > copying and etc. This will trigger frequent long Java GC pause to scan > references, to update references lists, and to copy live objects from > one memory location to another blindly. > > 3) The Unpredictable GC Pause: For latency sensitive applications, > such as database, search engine, web query, real-time/streaming > computing, require latency/request-response under control. But current > Java GC does not provide predictable GC activities with large on-heap > memory management. > > 4) High JNI Invocation Cost: JNI calls are expensive, but high > performance applications usually try to leverage native code to >
Re: [DISCUSS] Mnemonic incubator proposal
Hey YanPing, This addition is nice to see. I agree that there is great opportunity for the Arrow and Mnemonic communities to collaborate. I look forward to working together. Jacques On Mon, Feb 22, 2016 at 3:01 PM, Wang, Yanping wrote: > Hi, All > > Based on feedback, we added following into Mnemonic proposal: > > Relationships with Other Apache Product > + Relationship with Apache™ Arrow: > + Arrow's columnar data layout allows great use of CPU caches & SIMD. It > places all data that relevant to a column operation in a compact format in > memory. > + > + Mnemonic directly puts the whole business object graphs on external > heterogeneous storage media, e.g. off-heap, SSD. It is not necessary to > normalize the structures of object graphs for caching, checkpoint or > storing. It doesn’t require developers to normalize their data object > graphs. Mnemonic applications can avoid indexing & join datasets compared > to traditional approaches. > + > + Mnemonic can leverage Arrow to transparently re-layout qualified data > objects or create special containers that is able to efficiently hold those > data records in columnar form as one of major performance optimization > constructs. > + > > Thanks > Yanping > > -Original Message- > From: Wang, Yanping [mailto:yanping.w...@intel.com] > Sent: Sunday, February 21, 2016 11:47 AM > To: general@incubator.apache.org > Subject: [DISCUSS] Mnemonic incubator proposal > > Hi all > > We'd like to start a discussion regarding a proposal to submit Mnemonic to > the Apache Incubator. > > The proposal text is available on the Wiki here: > https://wiki.apache.org/incubator/MnemonicProposal > > and pasted below for convenience. > > We are excited to make this proposal, and look forward to the community's > input! > > Best, > Yanping > > > = Mnemonic Proposal = > === Abstract === > Mnemonic is a Java based non-volatile memory library for in-place > structured data processing and computing. It is a solution for generic > object and block persistence on heterogeneous block and byte-addressable > devices, such as DRAM, persistent memory, NVMe, SSD, and cloud network > storage. > > === Proposal === > Mnemonic is a structured data persistence in-memory in-place library for > Java-based applications and frameworks. It provides unified interfaces for > data manipulation on heterogeneous block/byte-addressable devices, such as > DRAM, persistent memory, NVMe, SSD, and cloud network devices. > > The design motivation for this project is to create a non-volatile > programming paradigm for in-memory data object persistence, in-memory data > objects caching, and JNI-less IPC. > Mnemonic simplifies the usage of data object caching, persistence, and > JNI-less IPC for massive object oriented structural datasets. > > Mnemonic defines Non-Volatile Java objects that store data fields in > persistent memory and storage. During the program runtime, only methods and > volatile fields are instantiated in Java heap, Non-Volatile data fields are > directly accessed via GET/SET operation to and from persistent memory and > storage. Mnemonic avoids SerDes and significantly reduces amount of garbage > in Java heap. > > Major features of Mnemonic: > * Provides an abstract level of viewpoint to utilize heterogeneous > block/byte-addressable device as a whole (e.g., DRAM, persistent memory, > NVMe, SSD, HD, cloud network Storage). > * Provides seamless support object oriented design and programming without > adding burden to transfer object data to different form. > * Avoids the object data serialization/de-serialization for data > retrieval, caching and storage. > * Reduces the consumption of on-heap memory and in turn to reduce and > stabilize Java Garbage Collection (GC) pauses for latency sensitive > applications. > * Overcomes current limitations of Java GC to manage much larger memory > resources for massive dataset processing and computing. > * Supports the migration data usage model from traditional NVMe/SSD/HD to > non-volatile memory with ease. > * Uses lazy loading mechanism to avoid unnecessary memory consumption if > some data does not need to use for computing immediately. > * Bypasses JNI call for the interaction between Java runtime application > and its native code. > * Provides an allocation aware auto-reclaim mechanism to prevent external > memory resource leaking. > > > === Background === > Big Data and Cloud applications increasingly require both high throughput > and low latency processing. Java-based applications targeting the Big Data > and Cloud space should be tuned for better throughput, lower latency, and > more predictable response time. > Typically, there are some issues that impact BigData applications' > performance and scalability: > > 1) The Complexity of Data Transformation/Organization: In most cases, > during data processing, applications use their own complicated data caching > mechanism for SerDes data objects, spilling to different storage and > e
Re: FW: [DISCUSSION] How to deal with runtime dependencies
I've used this as reference previously: http://www.apache.org/legal/resolved.html#prohibited Specifically this sentence: "...For example, using a GPL'ed tool during the build is OK." That would suggest that using GPL tools for build and test should be okay. I'll let others address the distribution of optional components question in great detail. My sense is this is primarily focused on how "optional" the undistributable component is. On Wed, Feb 10, 2016 at 12:56 AM, Markus Geiß wrote: > Hey all, > > We've started a thread at our dev list and forgot to send it to the > general incubator list too. > Any opinion is appreciated, you can find the original message below. > > Best, > > Markus > > .::YAGNI likes a DRY KISS::. > > > From: markus.ge...@live.de > > To: d...@fineract.incubator.apache.org > > Subject: [DISCUSSION] How to deal with runtime dependencies > > Date: Mon, 8 Feb 2016 14:12:04 +0100 > > > > Hey all, > > > > hope this finds you well. > > > > I thought instead of discussing this on top of pull request, because it > is more > > than just the JDBC driver, it is the right time to create a new thread. > > > > We are currently using MySQL's Connector/J and Hibernate's EntityManager > at > > runtime as the JDBC driver and JPA implementation. Our source code is not > > depending on both. > > > > It would create a huge effort to replace both for test and production > environments. > > > > The questions is: > > > > Would it be compliant with the license policies if we omit them for our > source > > release, but keeping them for our own integration tests. > > > > If somebody is creating a deployable distribution, the expectation is > that whomever > > is creating the distribution can decide what he wants to use. > > > > Best, > > > > Markus > > > > .::YAGNI likes a DRY KISS::. >
Re: [VOTE] Accept Guacamole into the Apache incubator
+1 binding - Jacques Nadeau On Feb 2, 2016 8:11 PM, "Greg Trasuk" wrote: > > +1 (Binding) - Greg Trasuk > > > > On Feb 2, 2016, at 10:05 AM, Jean-Baptiste Onofré > wrote: > > > > Hi, > > > > The Guacamole proposal was discussed couple of weeks ago. > > > > The complete discussion thread is available here: > > > > > http://mail-archives.apache.org/mod_mbox/incubator-general/201601.mbox/%3c56a5c8c3.7070...@guac-dev.org%3E > > > > As reminder the GuacamoleProposal is here: > > > > https://wiki.apache.org/incubator/GuacamoleProposal > > > > As we received only positive feedbacks in the discussion thread, we > think it's time to call for a vote to accept Guacamole into the Incubator. > > > > Please cast your vote to: > > [] +1 - accept Apache Guacamole as a new incubating project > > [] 0 - not sure > > [] -1 - do not accept the Apache Guacamole project (because: ...) > > > > Thanks, > > Regards > > JB > > > > > > = GuacamoleProposal = > > > > == Abstract == > > > > Guacamole is an enterprise-grade, protocol-agnostic, remote desktop > gateway. Combined with cloud hosting, Guacamole provides an excellent > alternative to traditional desktops. Guacamole aims to make cloud-hosted > desktop access preferable to traditional, local access. > > > > == Background == > > > > Guacamole began in 2010 as a personal project - a means for Mike Jumper > to access to his own computer from work. Mike’s job at that time had a > firewall which blocked outbound access to everything except HTTP and HTTPS, > and directly circumventing the firewall (by changing the SSH server port, > for example) was a fireable offense. Mike needed a solution which provided > remote access and yet was a true web application. He found several projects > providing text-based terminal access, but decided that he wanted to make > something new and different. > > > > The project began as a simple VNC client but grew rapidly in capability > and performance until it became an enterprise-grade, protocol-agnostic, > remote desktop gateway supporting both VNC and RDP. Support for SSH was > added later, followed by audio, file transfer, etc. By this point, > Guacamole was fast and stable enough to be used daily and in place of a > traditional desktop. > > > > Having used and developed Guacamole to its current state, and having > observed the general shift of the industry toward cloud computing and > related technologies, we now see Guacamole as the primary and only viable > open source solution for a future of cloud-hosted desktops. > > > > Guacamole's purpose is twofold: > > > > * To provide seamless and performant access to desktops over the web. > > * To provide an API which allows others, including commercial entities, > to integrate Guacamole's core into their own applications. > > > > We believe that the lifestyle enabled by Guacamole should be preferable > to traditional, physically-anchored desktops, that the software enabling > this should be 100% free in every sense of the word, and that users should > not be limited by their current location, by the software installed on > whatever computer they are using at the moment, nor by how powerful/weak > the hardware of that computer happens to be. > > > > Guacamole is stable and production-ready. It is in active production use > by several companies, including ESI, Glyptodon, HP, Nanocloud Software, as > well as individuals. > > > > == Rationale == > > > > Due to the utility and popularity of cloud platforms, a logical > extension to traditional application hosting is to host complete desktops. > The Guacamole project is aimed at achieving this, and we believe that the > best way to fulfill the true potential of this project is to bring its > development within Apache and, by so doing, foster a larger community and > higher visibility. The resulting continuous improvements to its design and > implementation will make Guacamole the best tool for the job for a wide > variety of use cases. > > > > == Initial Goals == > > > > Our initial goals are to bring Guacamole into the ASF, transition > internal engineering processes into the open, and foster a collaborative > development model according to the "Apache Way." > > > > == Current Status == > > > > Guacamole is production-ready and already provides a large set of > features. It is currently licensed under the MIT license, but will be > relicensed under the Apache license if accepted for incubation. > > > > The so
Re: [VOTE] Release Apache Myriad 0.1.0 (incubating)
I tried to build and got this message: $ brew install gradle ==> Downloading https://downloads.gradle.org/distributions/gradle-2.8-bin.zip 100.0% 🍺 /usr/local/Cellar/gradle/2.8: 164 files, 47M, built in 6 seconds $ gradle wrapper ... $ ./gradlew build ... FAILURE: Build failed with an exception. * What went wrong: Could not resolve all dependencies for configuration ':myriad-scheduler:compile'. > Could not find zookeeper-tests.jar (org.apache.zookeeper:zookeeper:3.4.6). Searched in the following locations: file:/Users/jnadeau/.m2/repository/org/apache/zookeeper/zookeeper/3.4.6/zookeeper-3.4.6-tests.jar Did I miss a step? $ java -version java version "1.7.0_80" Java(TM) SE Runtime Environment (build 1.7.0_80-b15) Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode) thanks, Jacques On Mon, Dec 7, 2015 at 3:26 PM, Santosh Marella wrote: > Hello All, > > Appreciate if IPMC members can review the RC and vote. > > Thanks, > Santosh > > On Thu, Dec 3, 2015 at 1:27 AM, Santosh Marella > wrote: > > > Hello All, > > > > Just a reminder that this vote is still open. > > > > We've received feedback, and a binding +1, from just one IPMC member > > (Justin Mclean). Appreciate if more folks can try out the RC and vote. > > > > Thanks, > > Santosh > > > > On Mon, Nov 30, 2015 at 7:59 PM, Santosh Marella > > wrote: > > > >> Thanks Justin. Appreciate your feedback. > >> > >> > You may want to also double check the version of bootstrap you have > >> bundled, the comment says 3.2 and that it is Apache licensed, however > >> > github shows 3.2 is MIT licensed. [1] I think the change from Apache > to > >> MIT happened at around 3.0.3. [2] If this is the case can you add > bootstrap > >> > to the LICENSE file in the next release. However it may be that > Twitter > >> didn’t update the header of this file. If that's the case I’d just > leave it > >> as it is. > >> > >> The bootstrap css bundled with Myriad was generated using > >> http://bootswatchr.com/ by selecting version "3.2" of bootstrap. I > >> suspect bootswatchr is not including the right license header. > >> > >> /*! > >> * Bootstrap v3.2 > >> * > >> * Copyright 2014 Twitter, Inc > >> * Licensed under the Apache License v2.0 > >> * http://www.apache.org/licenses/LICENSE-2.0 > >> * > >> * Designed and built with all the love in the world by @mdo and @fat. > >> * BootSwatchr built and provided by @DrewStrickland > >> */ > >> /*! normalize.css v3.0.1 | MIT License | git.io/normalize */ > >> > >> Created https://issues.apache.org/jira/browse/MYRIAD-177 to fix this > for > >> the next release. > >> > >> Thanks, > >> Santosh > >> > >> On Mon, Nov 30, 2015 at 5:47 PM, Justin Mclean < > jus...@classsoftware.com> > >> wrote: > >> > >>> Hi, > >>> > >>> +1 binding. > >>> > >>> I checked: > >>> - release name contains incubating > >>> - signature and hash good > >>> - DISCLAIMER exists > >>> - LICENSE and NOTICE good. May be minor LICENSE issue re bootstrap (see > >>> below). > >>> - no unexpected binary files > >>> - all source files have Apache headers > >>> - can compile from source > >>> > >>> You might want to in the next release sign the release with an apache > >>> email address. > >>> > >>> You may want to also double check the version of bootstrap you have > >>> bundled, the comment says 3.2 and that it is Apache licensed, however > >>> github shows 3.2 is MIT licensed. [1] I think the change from Apache > to MIT > >>> happened at around 3.0.3. [2] If this is the case can you add > bootstrap to > >>> the LICENSE file in the next release. However it may be that Twitter > didn’t > >>> update the header of this file. If that's the case I’d just leave it > as it > >>> is. Sorry I missed this last time. > >>> > >>> I also had to increase the memory in gradle.properties to get the > >>> project to compile without an out of heap space error but that may > just be > >>> my setup. > >>> > >>> Thanks, > >>> Justin > >>> > >>> 1. https://github.com/twbs/bootstrap/tree/v3.2.0 < > >>> https://github.com/twbs/bootstrap/tree/v3.2.0> > >>> 2. https://github.com/twbs/bootstrap/tree/v3.0.3 < > >>> https://github.com/twbs/bootstrap/tree/v3.0.3> > >>> > >>> > >> > > >
Re: [VOTE] Accept Metron into Apache Incubator
+1 (binding) Jacques On Fri, Dec 4, 2015 at 8:10 AM, Amol Kekre wrote: > +1 (non-binding) > > Amol > > > On Fri, Dec 4, 2015 at 8:02 AM, Ryan Merriman > wrote: > > > +1 (non-binding) > > > > > > On 12/4/15, 10:00 AM, "james sirota" > > wrote: > > > > >+1 (non-binding) > > > From: Billie Rinaldi > > > To: general@incubator.apache.org > > > Sent: Friday, December 4, 2015 8:06 AM > > > Subject: Re: [VOTE] Accept Metron into Apache Incubator > > > > > >+1 (binding) > > > > > >On Thu, Dec 3, 2015 at 12:33 PM, Owen O'Malley > > wrote: > > >> The [DISCUSS] thread has would down, so I'd like to start a VOTE on > > >whether > > >> Apache Incubator should accept Metron as a podling. The proposal is > > >>pasted > > >> below and is available on the wiki as well. > > >> > > >> https://wiki.apache.org/incubator/MetronProposal > > >> > > >> We've added a paragraph in the background section discussing how > Apache > > >> avoids hostile forks of projects, because we don't want to fork > > >> communities. We've also added Larry McCay, P. Taylor Goetz, and > Phillip > > >> Rhodes to the proposal. > > >> > > >> The vote will run until 12pm PST on Sunday. > > >> > > >> Thanks, > > >>Owen > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
Re: [RESULT] [VOTE] Accept Impala into the Apache Incubator
A few thoughts from a 'bystander': It's great that Greg and the others who disagree cast their dissenting votes. That doesn't mean that we should throw out process. If the process is 3x+1 and more +1 than -1, this vote passes as Henry stated. Greg even stated (if I understand his statements correctly) that he was not trying to sink this vote but rather to express his dissent. RTC versus CTR is clearly a religious debate. There are a large number of successful and vibrant Apache communities using each paradigm. I don't think this new community can address those -1's unless they switched religious sides. That seems to be an unfair ask given their desires and the general split on this topic within the broader Apache membership. (In other words, short of switching to CTR, it seems like these -1's would stand.) Adding additional mentors seems to be a late suggestion and unwarranted. The mentors on this proposal have strong Apache credentials and there is reasonable diversity among them. On Tue, Dec 1, 2015 at 5:40 PM, Roman Shaposhnik wrote: > On Tue, Dec 1, 2015 at 5:07 PM, Ralph Goers > wrote: > > The only mention of consensus I could find is in the actual development > of the actual > > proposal. I’m sure one could argue that that implies that whether > consensus is achieved > > is by the vote, but with a group as large as the IPMC it would be > horrible to allow a > > single vote to block a podling from entering. > > Right. But imagine if INFRA representative cast -1 because we don't > have resources > to accommodate the poddling will we still use simple majority? > > To me this highlights a very fundamental problem with an incubator: > give the size > of the PMC if we start allowing simple majority to just "happen" > without any semblance > of trying to address concerns by a compromise of some sorts -- we're > running a significant > risk of never EVER be able to say NO to a podling when we need to. > > I have not seen folks proposing Impala considering any compromise that > would > alleviate concerns that were articulated by -1 votes. I see a lot of > 'this is our way -- we > don't want to change' attitude. That is *precisely* why I personally > cast a -1, btw. > > Now, if you're looking for ideas on how a compromise would look like > things like > inviting more diverse set of mentors, etc may be a good place to start > (I'm obviously > brainstorming here). > > Thanks, > Roman. > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Accept Kudu into the Apache Incubator
+1 Great to see this coming to the foundation! On Tue, Nov 24, 2015 at 11:33 AM, Todd Lipcon wrote: > On Tue, Nov 24, 2015 at 11:32 AM, Todd Lipcon wrote: > > > Hi all, > > > > Discussion on the [DISCUSS] thread seems to have wound down, so I'd like > > to call a VOTE on acceptance of Kudu into the ASF Incubator. The proposal > > is pasted below and also available on the wiki at: > > https://wiki.apache.org/incubator/KuduProposal > > > > The proposal is unchanged since the original version, except for the > > addition of Carl Steinbach as a Mentor. > > > > Please cast your votes: > > > > [] +1, accept Kudu into the Incubator > > [] +/-0, positive/negative non-counted expression of feelings > > [] -1, do not accept Kudu into the incubator (please state reasoning) > > > > > I'll start the voting with my +1 (binding, assuming it's permitted to vote > on your own proposal!) >
Re: Project Website Template
+1. The Jekyll flow is great and has a low learning curve. On Sat, Nov 7, 2015 at 3:12 PM, larry mccay wrote: > +1 - this would be a great resource for bootstrapping a new project! > > On Sat, Nov 7, 2015 at 5:35 PM, Julian Hyde wrote: > > > +1 > > > > I had the same thought when I built Calcite’s site based on jekyll > > (actually cloned from Orc’s site). Thanks for making this template — I’m > > sure it will be helpful to new projects. > > > > We should make it clear that it is optional, of course. But when Calcite > > entered the incubator there were entirely too many choices (and > > opportunities to make mistakes). The whole svnpubsub vs cms question, for > > instance, delayed our web site by about 6 months because we weren’t sure > > whether we could backtrack once we had made a decision. So I think it > would > > be useful if there were some default choices to get incubator projects > off > > and running quickly. > > > > I also think it would be useful to provide a template for maven/java > based > > projects. There would be a pom.xml, module/pom.xml and > > module/org/apache/foo/Foo.java, and just enough content in the pom.xml to > > be able to make a release by typing “mvn release:prepare … mvn > > release:perform”. If anyone is interested I’ll do it. > > > > Luciano, Did you have a place in mind to put your template site? I think > > it would need to be in an apache project, not in github, so that any > > podling can import it without worrying about IP contamination. > > > > Julian > > > > > > > > > On Nov 7, 2015, at 1:21 PM, Ted Dunning wrote: > > > > > > > > > Easy is good > > > > > > > > > The Jekyll work flow has worked well in the project I have mentored. > > > > > > Sent from my iPhone > > > > > >> On Nov 7, 2015, at 10:04, Luciano Resende > wrote: > > >> > > >> I have just spent a day or so building a new podling website based on > > >> Jekyll and I tried to model it as a template, where a new > > project/podling > > >> can easily modify _data/project.yml and configure it's name, dev list, > > user > > >> list, jira, source repository, etc. > > >> > > >> I was wondering if this would be good as a "template" where new > projects > > >> that come on board could easily fork to start their website and just > > change > > >> the styles and contents of main page, and voila, the site would be > > ready, > > >> with all the required trademarks and other apache requirements, etc > > >> > > >> Thoughts ? > > >> > > >> -- > > >> Luciano Resende > > >> http://people.apache.org/~lresende > > >> http://twitter.com/lresende1975 > > >> http://lresende.blogspot.com/ > > > > > > - > > > 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: [ANNOUNCE] Six new Incubator PMC members
Thanks! Looking forward to helping out in new ways. On Fri, Nov 6, 2015 at 9:57 PM, Henry Saputra wrote: > Welcome! > > On Fri, Nov 6, 2015 at 8:43 PM, Marvin Humphrey > wrote: > > Greetings, > > > > I'm delighted to welcome six new members of the Incubator PMC! > > > > * Tom Barber (magicaltrout), PMC Chair of OODT. > > * Patrick Wendell (pwendell), PMC member of Spark and committer > > on Avro and Flume. > > * Reynold Xin (rxin), PMC member of Spark. > > * Phil Sorber (sorber), PMC member for TrafficServer. > > * Julien Le Dem (julien), PMC Chair of Parquet, PMC member of Pig and > Tez. > > * Jacques Nadeau (jacques), PMC Chair of Drill, PMC member of Calcite. > > > > Welcome aboard -- we can't wait to see how you will help our podling > > communities succeed! > > > > 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 > >
Request to join IPMC
I would like to join the IPMC. I'm PMC Chair of Drill, a PMC member for Calcite and have also contributed to Parquet & HBase. Let me know what you need. thanks, Jacques
Re: [VOTE] Graduate Calcite from the Apache Incubator
+1 (non-binding). Props go especially to Julian for all that he has done to establish the community. On Tue, Sep 15, 2015 at 10:14 PM, Steven Noels wrote: > On Tue, Sep 15, 2015, at 03:56 AM, Julian Hyde wrote: > > > This is a vote for Calcite to become a top-level project. > > > > Since joining the Incubator in May, 2014, the Calcite > > community has: > > * Produced eight IPMC-approved releases under two release > > managers; > > * Added five new committers and one new PPMC member; > > * Collaborated successfully with several other Apache > > projects (Drill, Hive, Kylin, Phoenix, Samza); > > * Grown into an active community (typical monthly activity > > is 100 emails, 30 commits and 20 issues fixed); > > * Conducted a successful community vote to graduate with > > 20 +1 votes, of which 2 were from our mentors, 12 were > > from committers, and 6 were from IPMC members. > > > > Further information: the discussion on the dev list [1], > > vote thread [2] and result [3]. Also relevant are the > > incubation status page [4] and a thread on this list > > requesting review of whether Calcite met the criteria to > > graduate [5]. > > > > Below is our proposed resolution for the Board. > > > > Please vote: > > > > [ ] +1 Graduate Apache Calcite as a top-level project > > [ ] +0 > > [ ] -1 Do not graduate Apache Calcite because… > > Enthusiastic +1 > > Great job! > > Steven. > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[RESULT][VOTE] Release apache-calcite-1.4.0-incubating
This vote passes with 4 +1s, one +0 and no -1 votes: +1 Alan (Mentor) +1 Ashutosh (Mentor) +1 Julian +1 John +0 Justin Thanks everyone. We’ll now roll the release out to the mirrors. Jacques On Mon, Aug 31, 2015 at 4:51 PM, Ashutosh Chauhan wrote: > Forwarding my +1 from Calcite list. > > Ashutosh > > On Mon, Aug 31, 2015 at 10:59 AM, Alan Gates wrote: > >> Forwarding my +1 from the Calcite vote. >> >> Alan. >> >> Jacques Nadeau >> August 28, 2015 at 14:32 >> Hi all, >> >> The Calcite community has voted on and approved a proposal to release >> Apache Calcite 1.4.0-incubating. >> >> Proposal: >> >> http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CCAKa9qD%3DWA1s03rUEuCUbUbWiBgmC_9N%3D1r39dXjLAKevRt6UCQ%40mail.gmail.com%3E >> >> Vote result: >> 8 binding +1 votes >> 1 non-binding +1 votes >> No -1 votes >> >> http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CCAKa9qD%3DPUH70eyPY3u25O4ayimwOXfBBxiX2txUEcNbUCYODXg%40mail.gmail.com%3E >> >> The commit to be voted upon: >> >> http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/0c0c203daec56c05b6c75fa3896c8af19844df68 >> >> Its hash is 0c0c203daec56c05b6c75fa3896c8af19844df68. >> >> The artifacts to be voted on are located here: >> >> https://dist.apache.org/repos/dist/dev/incubator/calcite/apache-calcite-1.4.0-incubating-rc0 >> >> The hashes of the artifacts are as follows: >> src.tar.gz.md5 e052e2b1ffdbdab9eaeb30f4ac838e75 >> src.tar.gz.sha1 fd979e8b330bb0d3b9be8625c95589e0eb358722 >> src.zip.md5 ef1880617f3b6415c5e3779d9c2bbc10 >> src.zip.sha1 b865a9a45046a339c53834e7abea7a7a55927f07 >> >> A staged Maven repository is available for review at: >> https://repository.apache.org/content/repositories/orgapachecalcite-1009 >> >> Release artifacts are signed with the following key: >> https://people.apache.org/keys/committer/jacques.asc >> >> Pursuant to the Releases section of the Incubation Policy and with >> the endorsement of 2 of our mentors we would now like to request >> the permission of the Incubator PMC to publish the release. The vote >> is open for 72 hours, or until the necessary number of votes (3 +1) >> is reached. >> >> [ ] +1 Release this package as Apache Calcite 1.4.0-incubating >> [ ] -1 Do not release this package because... >> >> Jacques Nadeau, on behalf of Apache Calcite PPMC >> >> >
Re: [VOTE] Release apache-calcite-1.4.0-incubating
Hi Justin, I've filed CALCITE-860 and CALCITE-861 to address the issues you identified. We'll be sure to get them addressed for the next release. Thanks for reviewing the release and voting. Jacques On Sat, Aug 29, 2015 at 5:07 PM, Justin Mclean wrote: > Hi, > > +0 (binding) and please fix up the licensing issues for the next release. > > Checked: > - Release file name includes incubating > - DISCLAIMER exists > - LICENSE has some issues (see below), but all licenses involved are > permissive and Apache compatable. > - NOTICE ok > - No unexpected binary files > - Can compile from source > > While I managed to get it to compile, note that a “mvn compile” will fail > with: > Could not find artifact > org.apache.calcite:calcite-avatica:jar:tests:1.4.0-incubating in central > > LICENSE has some issues that need to be corrected: > - missing MIT license for ./site/_sass/_font-awesome.scss > - missing MIT license for ./site/_sass/_normalize.scs > - missing MIT license for /site/_sass/_gridism.scss > - missing MIT license for ./site/js/html5shiv.min.js > - missing MIT license for ./site/js/respond.min.js > - missing SIL license for ./site/fonts/fontawesome-webfont.* > > And I assume also missing SASS's MIT license. > > Please read [1] on how to add permissive licenses. Note that the licenses > have different copyright owners. > > Also what it the provenance of this file? > ./example/csv/src/test/resources/bug/archers.json > > It looks like it may be part of a script from The Archers [2], do you have > permission from the copyright owners to use this? > > Thanks, > Justin > > 1. http://www.apache.org/dev/licensing-howto.html#permissive-deps > 2. https://en.wikipedia.org/wiki/The_Archers > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release apache-calcite-1.4.0-incubating
Thanks for helping clarify Marvin. I didn't realize that Julian was an IPMC. I was only counting the two mentors that voted in our vote. On Fri, Aug 28, 2015 at 2:45 PM, Marvin Humphrey wrote: > On Fri, Aug 28, 2015 at 2:32 PM, Jacques Nadeau > wrote: > > > Vote result: > > 8 binding +1 votes > > 1 non-binding +1 votes > > No -1 votes > > > http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CCAKa9qD%3DPUH70eyPY3u25O4ayimwOXfBBxiX2txUEcNbUCYODXg%40mail.gmail.com%3E > > To remove the ambiguity: three IPMC members have voted +1: Ashutosh > Chauhan, Julian Hyde, and Alan Gates. > > Marvin Humphrey > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[VOTE] Release apache-calcite-1.4.0-incubating
Hi all, The Calcite community has voted on and approved a proposal to release Apache Calcite 1.4.0-incubating. Proposal: http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CCAKa9qD%3DWA1s03rUEuCUbUbWiBgmC_9N%3D1r39dXjLAKevRt6UCQ%40mail.gmail.com%3E Vote result: 8 binding +1 votes 1 non-binding +1 votes No -1 votes http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201508.mbox/%3CCAKa9qD%3DPUH70eyPY3u25O4ayimwOXfBBxiX2txUEcNbUCYODXg%40mail.gmail.com%3E The commit to be voted upon: http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/0c0c203daec56c05b6c75fa3896c8af19844df68 Its hash is 0c0c203daec56c05b6c75fa3896c8af19844df68. The artifacts to be voted on are located here: https://dist.apache.org/repos/dist/dev/incubator/calcite/apache-calcite-1.4.0-incubating-rc0 The hashes of the artifacts are as follows: src.tar.gz.md5 e052e2b1ffdbdab9eaeb30f4ac838e75 src.tar.gz.sha1 fd979e8b330bb0d3b9be8625c95589e0eb358722 src.zip.md5 ef1880617f3b6415c5e3779d9c2bbc10 src.zip.sha1 b865a9a45046a339c53834e7abea7a7a55927f07 A staged Maven repository is available for review at: https://repository.apache.org/content/repositories/orgapachecalcite-1009 Release artifacts are signed with the following key: https://people.apache.org/keys/committer/jacques.asc Pursuant to the Releases section of the Incubation Policy and with the endorsement of 2 of our mentors we would now like to request the permission of the Incubator PMC to publish the release. The vote is open for 72 hours, or until the necessary number of votes (3 +1) is reached. [ ] +1 Release this package as Apache Calcite 1.4.0-incubating [ ] -1 Do not release this package because... Jacques Nadeau, on behalf of Apache Calcite PPMC
Re: [VOTE] Apache Drill 0.6.0-incubating release
This vote thread looks like a hanging chad. The current vote count is: +1 Ted +1 Lars +1 Justin +1 or -1: Grant -0 Jan I would love to have a clarification vote from Grant. I read his concern and the subsequent messages to mean +1 but I'm a bit biased as I'd like to see this release go out. Whatever the case, I suggest we give 24 hours for additional feedback and then finish the vote. If Grant does not clarify his stance, I propose that we ignore his ambiguous vote. Steven, how does that sound? thanks, Jacques On Tue, Oct 14, 2014 at 8:46 AM, Ted Dunning wrote: > On Tue, Oct 14, 2014 at 7:24 AM, sebb wrote: > > > > If it contains sources, it's not a binary release. > > > > Not strictly true. Binary artifacts often contain source code examples. > > > Also, for Drill specifically, the code generation strategy that Drill uses > requires that snippets of source for different operators and system > packaged UDF's will be in the binary release. The user has no clue about > this source, much of which is machine generated from templates. > > From the user's point of view, however, it is a binary distro because they > can download it and run Drill with no further build steps. >
[ANNOUNCE] Announcing the release of Apache Drill 0.5.0-incubating
Hello Everybody, I'm pleased to announce the 0.5.0 release of Apache Drill. It includes a huge amount of work from everyone in the community. You can read more about it on our blog [1] or check out the release notes [2]. Download it now [3] and let us know what you think! [1] https://blogs.apache.org/drill/ [2] https://cwiki.apache.org/confluence/display/DRILL/Apache+Drill+0.5.0+Release+Notes [3] http://incubator.apache.org/drill/download.html
[RESULT] [VOTE] Apache Drill 0.5.0-incubating release
Thanks for everybody's input. The release vote passes with three +1's and no -1's. The votes were from: Ted +1 Jan +1 John +1 Note that sebb also has a +1 on this thread but it is about improving the documentation, not the Drill release artifacts. Thanks to everyone. We'll move forward with propagating to Apache mirrors. Jacques On Tue, Sep 9, 2014 at 5:50 AM, sebb wrote: > On 9 September 2014 13:24, jan i wrote: > > On 9 September 2014 06:51, Ted Dunning wrote: > > > >> John, > >> > >> Actually, on reading the links you provide, neither provides solid > guidance > >> about the issue in question. The second link comes closest where it > says > >> that projects typically use one of three different methods. How does > this > >> document your strong preference for a single one of these alternatives? > >> > > If we really have a strong preference or even a mandatory way of doing > > this, then it should be clearly stated and not something different people > > interpret differently. > > > > I see > > https://dist.apache.org/repos/dist/dev/xyz > > > > as an elegant way of doing it, let me put it differently if a project > > prefer to it differently it might not be elegant enough (or well > > documented). > > > > I think we really need to be careful not to make rules just because we > can. > > Giving projects freedom where possible should be our goal. > > +1 > > However, we need to document what functions the process needs to support. > > For example, the release vote e-mail should uniquely identify the > release artifacts so that they can be traced back from the public > release area to the vote e-mail. > > Also the vote email should provide sufficient information that anyone > can check the release without needing to search for additional > information (e.g. it should link to KEYS etc) > > i.e. we need to document _what_ must be done, without necessarily > prescribing _how_ to do it. > Though of course it helps to document a recommended process that meets > the requirements. > > > just my opinion. > > rgds > > jan i. > > > > > >> > >> > >> > >> On Mon, Sep 8, 2014 at 4:27 PM, John D. Ament > >> wrote: > >> > >> > Ted, > >> > > >> > Do you mean more than here: > >> > > >> > [1]: http://www.apache.org/dev/publishing-maven-artifacts.html > >> > [2]: http://www.apache.org/dev/release.html#host-rc > >> > > >> > On Mon, Sep 8, 2014 at 7:12 PM, Ted Dunning > >> wrote: > >> > > >> > > Is the new process documented somewhere? > >> > > > >> > > > >> > > > >> > > > >> > > On Mon, Sep 8, 2014 at 3:17 PM, sebb wrote: > >> > > > >> > > > On 7 September 2014 20:31, Jacques Nadeau > >> wrote: > >> > > > > As I understand the release guidelines, one is not allowed to > put > >> > > > something > >> > > > > on dist.apache.org until after a release vote by the Incubator > PMC > >> > > > approves > >> > > > > that release: > >> > > > > > >> > > > > "Only formally-approved releases may be distributed from the > main > >> > > > > directories" [1] > >> > > > > > >> > > > > For this candidate, as with our last two releases, we followed > this > >> > > piece > >> > > > > of information: > >> > > > > > >> > > > > "It is traditional that release managers use their Apache home > >> space > >> > to > >> > > > > make available release candidates. " [1] > >> > > > > >> > > > Historic tradition; that was before svnpubsub. > >> > > > > >> > > > Note that the DEV tree at > >> > > > > >> > > > https://dist.apache.org/repos/dist/dev/xyz > >> > > > > >> > > > is NOT published to www.apache.org/dist > >> > > > > >> > > > The svnpubsub process takes releases from the RELEASE tree at > >> > > > > >> > > > https://dist.apache.org/repos/dist/release/xyz > >> > > > > >> > > > Since they have the same parent, one can use svn move (or > svnmucc) to > >> >
Re: [VOTE] Apache Drill 0.5.0-incubating release
Hey John, Thanks for the vote and the information. I didn't even realize that the dist.a.o/dev folder existed at until I read your reference at [1]. Always new things to learn. I guess that is another option as opposed to the old skool people.a.o. [1]: http://www.apache.org/dev/release.html#host-rc On Sun, Sep 7, 2014 at 12:48 PM, John D. Ament wrote: > On Sun, Sep 7, 2014 at 3:39 PM, jan i wrote: > > > On 7 September 2014 21:31, Jacques Nadeau wrote: > > > > > As I understand the release guidelines, one is not allowed to put > > something > > > on dist.apache.org until after a release vote by the Incubator PMC > > > approves > > > that release: > > > > > > "Only formally-approved releases may be distributed from the main > > > directories" [1] > > > > > > For this candidate, as with our last two releases, we followed this > piece > > > of information: > > > > > > "It is traditional that release managers use their Apache home space to > > > make available release candidates. " [1] > > > > > I do agree with your POW. Important is: > > - The release bits are in SVN > > - The PMC vote is based on the same location presented for IPMC vote. > > > > dist.a.o is for approved releases, and I have found no "rule" stating a > > mandatory location to use for the vote itself. > > > > > Hmm Ok, now that I re-read the maven and release policy at [1] and [2], I > guess it's a wherever it ends up type of thing. > > With that said, I'll switch to a +1 > > [1]: http://www.apache.org/dev/publishing-maven-artifacts.html > [2]: http://www.apache.org/dev/release.html#host-rc > > > > > > rgds > > jan i. > > > > > > > > To date, we only push to dist.apache.org once we have received > approval > > > here. Can you point me to the guidelines that lead you to believe that > > > this must be staged on dist.apache.org? > > > > > > Thanks, > > > Jacques > > > > > > [1] > > > > > > > > > http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Sep 7, 2014 at 11:48 AM, John D. Ament > > > > wrote: > > > > > > > Sorry, I have to vote -1 > > > > > > > > The release is not staged in the proper place (e.g. > > > > https://dist.apache.org/repos/dist/dev/incubator/ ) > > > > > > > > If this gets moved, I can vote +1 > > > > > > > > On Sun, Sep 7, 2014 at 11:29 AM, Jacques Nadeau > > > > wrote: > > > > > > > > > Hi John, > > > > > > > > > > Thanks for the feedback. I'd like to respond to each of your > > concerns: > > > > > > > > > > >>Your NOTICE file is missing MIT license. > > > > > > > > > > The notice file states: "Please see LICENSE for additional > copyright > > > and > > > > > licensing information." The LICENSE file contains the MIT license. > > > > > > > > > > >>Your source file includes binaries in the sample-data directory. > > > > > > > > > > These are small sample data files that are used to do various unit > > > tests. > > > > > They have been approved on both of our previous releases because > of > > > > their > > > > > small size (<24k combined) and the fact that they are not source > > code. > > > > > These are raw data files that happen to be binary in nature but > are > > > for > > > > > all purposes the same as example json files we include for testing > > > > > purposes. > > > > > > > > > > >> Ideally, your directory name should match the release version > > > > (0.5.0.rc2 > > > > > vs 0.5.0) > > > > > > > > > > The name of the release candidate directory is due to the nature of > > the > > > > > Apache voting process. Each time we have a release candidate in > the > > > > > community, we hold a vote. We always maintain past release > > candidates > > > so > > > > > that we can refer back to them. All artifacts in the release > > candidate > > > > > hold the release/public names
Re: [VOTE] Apache Drill 0.5.0-incubating release
As I understand the release guidelines, one is not allowed to put something on dist.apache.org until after a release vote by the Incubator PMC approves that release: "Only formally-approved releases may be distributed from the main directories" [1] For this candidate, as with our last two releases, we followed this piece of information: "It is traditional that release managers use their Apache home space to make available release candidates. " [1] To date, we only push to dist.apache.org once we have received approval here. Can you point me to the guidelines that lead you to believe that this must be staged on dist.apache.org? Thanks, Jacques [1] http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote On Sun, Sep 7, 2014 at 11:48 AM, John D. Ament wrote: > Sorry, I have to vote -1 > > The release is not staged in the proper place (e.g. > https://dist.apache.org/repos/dist/dev/incubator/ ) > > If this gets moved, I can vote +1 > > On Sun, Sep 7, 2014 at 11:29 AM, Jacques Nadeau > wrote: > > > Hi John, > > > > Thanks for the feedback. I'd like to respond to each of your concerns: > > > > >>Your NOTICE file is missing MIT license. > > > > The notice file states: "Please see LICENSE for additional copyright and > > licensing information." The LICENSE file contains the MIT license. > > > > >>Your source file includes binaries in the sample-data directory. > > > > These are small sample data files that are used to do various unit tests. > > They have been approved on both of our previous releases because of > their > > small size (<24k combined) and the fact that they are not source code. > > These are raw data files that happen to be binary in nature but are for > > all purposes the same as example json files we include for testing > > purposes. > > > > >> Ideally, your directory name should match the release version > (0.5.0.rc2 > > vs 0.5.0) > > > > The name of the release candidate directory is due to the nature of the > > Apache voting process. Each time we have a release candidate in the > > community, we hold a vote. We always maintain past release candidates so > > that we can refer back to them. All artifacts in the release candidate > > hold the release/public names and will ultimately be hosted on the Apache > > distribution servers at the appropriately named release directory. For > > historical perspective on this, see the following that has been our > > strategy thus far: > > > > our m1 release: > > http://people.apache.org/~jacques/apache-drill-1.0.0-m1 (fail) > > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc2 (fail) > > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc3 (fail) > > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4 (approved) > --> > > and distributed as > > > https://archive.apache.org/dist/incubator/drill/drill-1.0.0-m1-incubating/ > > > > our 0.4.0 release: > > http://people.apache.org/~jacques/apache-drill-0.4.0.rc0 (fail) > > http://people.apache.org/~jacques/apache-drill-0.4.0.rc1 (approved) --> > > distributed as > > https://archive.apache.org/dist/incubator/drill/drill-0.4.0-incubating/ > > > > our 0.5.0 release: > > http://people.apache.org/~jacques/apache-drill-0.5.0.rc0 (fail) > > http://people.apache.org/~jacques/apache-drill-0.5.0.rc1 (fail) > > http://people.apache.org/~jacques/apache-drill-0.5.0.rc2 (pending) > > > > > > As you can see, the rc numbers are only used during the voting process. > > Once we get approval from the incubator, we drop the rc so that external > > consumers aren't confused by failed released candidates. > > > > Hopefully this satisfies your concerns and you can vote +1 for our > release. > > > > thanks again for your feedback, > > Jacques > > > > > > On Sun, Sep 7, 2014 at 5:09 AM, John D. Ament > > wrote: > > > > > Hi, > > > > > > Your NOTICE file is missing MIT license. > > > Your source file includes binaries in the sample-data directory. > > > Ideally, your directory name should match the release version > (0.5.0.rc2 > > vs > > > 0.5.0) > > > > > > John > > > > > > > > > On Sat, Sep 6, 2014 at 11:36 PM, Jacques Nadeau > > > wrote: > > > > > > > It is my pleasure to present the Apache Drill 0.5.0-incubating > release > > to > > > > the general incubator list for a vote. This set of artif
Re: [VOTE] Apache Drill 0.5.0-incubating release
Hi John, Thanks for the feedback. I'd like to respond to each of your concerns: >>Your NOTICE file is missing MIT license. The notice file states: "Please see LICENSE for additional copyright and licensing information." The LICENSE file contains the MIT license. >>Your source file includes binaries in the sample-data directory. These are small sample data files that are used to do various unit tests. They have been approved on both of our previous releases because of their small size (<24k combined) and the fact that they are not source code. These are raw data files that happen to be binary in nature but are for all purposes the same as example json files we include for testing purposes. >> Ideally, your directory name should match the release version (0.5.0.rc2 vs 0.5.0) The name of the release candidate directory is due to the nature of the Apache voting process. Each time we have a release candidate in the community, we hold a vote. We always maintain past release candidates so that we can refer back to them. All artifacts in the release candidate hold the release/public names and will ultimately be hosted on the Apache distribution servers at the appropriately named release directory. For historical perspective on this, see the following that has been our strategy thus far: our m1 release: http://people.apache.org/~jacques/apache-drill-1.0.0-m1 (fail) http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc2 (fail) http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc3 (fail) http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4 (approved) --> and distributed as https://archive.apache.org/dist/incubator/drill/drill-1.0.0-m1-incubating/ our 0.4.0 release: http://people.apache.org/~jacques/apache-drill-0.4.0.rc0 (fail) http://people.apache.org/~jacques/apache-drill-0.4.0.rc1 (approved) --> distributed as https://archive.apache.org/dist/incubator/drill/drill-0.4.0-incubating/ our 0.5.0 release: http://people.apache.org/~jacques/apache-drill-0.5.0.rc0 (fail) http://people.apache.org/~jacques/apache-drill-0.5.0.rc1 (fail) http://people.apache.org/~jacques/apache-drill-0.5.0.rc2 (pending) As you can see, the rc numbers are only used during the voting process. Once we get approval from the incubator, we drop the rc so that external consumers aren't confused by failed released candidates. Hopefully this satisfies your concerns and you can vote +1 for our release. thanks again for your feedback, Jacques On Sun, Sep 7, 2014 at 5:09 AM, John D. Ament wrote: > Hi, > > Your NOTICE file is missing MIT license. > Your source file includes binaries in the sample-data directory. > Ideally, your directory name should match the release version (0.5.0.rc2 vs > 0.5.0) > > John > > > On Sat, Sep 6, 2014 at 11:36 PM, Jacques Nadeau > wrote: > > > It is my pleasure to present the Apache Drill 0.5.0-incubating release to > > the general incubator list for a vote. This set of artifacts have passed > > our drill-dev vote and incorporate a number of improvements with over 100 > > JIRAs closed in the last month. > > > > As part of this release, we looked to address the feedback in our > previous > > release from the general list. This included enhancing our license and > > notice files as well as clearly delineating binary dependencies that are > > distributed as part of our convenience binary. > > > > The vote thread can be found here: > > > > > http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201409.mbox/%3CCAKa9qD=L9KLQbNe2BKXKn=H34r0=3boobbd_3uhzeojc9k8...@mail.gmail.com%3E > > > > The vote passed with: > > +5 binding > > +6 non-binding > > > > You can find the artifacts for the release at this location: > > http://people.apache.org/~jacques/apache-drill-0.5.0.rc2/ > > > > I look forward to your feedback. > > > > Thanks, > > Jacques > > >
[VOTE] Apache Drill 0.5.0-incubating release
It is my pleasure to present the Apache Drill 0.5.0-incubating release to the general incubator list for a vote. This set of artifacts have passed our drill-dev vote and incorporate a number of improvements with over 100 JIRAs closed in the last month. As part of this release, we looked to address the feedback in our previous release from the general list. This included enhancing our license and notice files as well as clearly delineating binary dependencies that are distributed as part of our convenience binary. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201409.mbox/%3CCAKa9qD=L9KLQbNe2BKXKn=H34r0=3boobbd_3uhzeojc9k8...@mail.gmail.com%3E The vote passed with: +5 binding +6 non-binding You can find the artifacts for the release at this location: http://people.apache.org/~jacques/apache-drill-0.5.0.rc2/ I look forward to your feedback. Thanks, Jacques
Re: [VOTE] Apache Drill 0.4.0-incubating release
One additional thought. As I'm thinking more about the NOTICE and LICENSE files I think it would be really helpful to have some reviews from you guys much earlier in the process than the next release vote. While the docs are helpful and we'll do our best, I'm skeptical we'll get it exactly right on our next attempt. Justin, would you be willing to review these changes once we get them up so that we can make sure we're not making other foolish mistakes? thanks, Jacques On Fri, Aug 8, 2014 at 8:18 AM, Jacques Nadeau wrote: > Hey guys, > > Sorry I didn't see Henry and Justin's comments until just now. Per > Justin's primary concerns about the License stuff: I think we've just made > mistakes in the notice and license files as to exactly how we reference > things. All the category B licenses are mvn binary dependencies (per the > third party dependencies rules), not source inclusions. To address > Justin's concerns, I've created the following JIRAs which we'll fix > straight away: DRILL-1274 and DRILL-1275 along with adding additional > requirements to DRILL-1271 in addition to Henry's previous notes on NOTICE > file. > > Given the following: > >- The mistakes are issues with documentation as opposed to invalid >source inclusions >- The vote was held open for 72 hours before being called >- Release artifacts are already on the mirrors >- This is a developer preview release with small distribution designed >primarily to expand the contributor community >- We plan on doing another release within a month where these can be >corrected. > > I'm going to go forward with this release. > > Thanks again to everyone for all the helpful feedback. I believe we are > making good progress. > > Jacques > > > > > > On Thu, Aug 7, 2014 at 5:44 PM, Justin Mclean > wrote: > >> Hi, >> >> > Ah, I saw disclaimer in the website [1] which I thought enough for >> incubator. >> > But checking the branding guide [2] seems like incubator need to >> > include DISCLAIMER file along with NOTICE and LICENSE files, so this >> > could be blocker? >> >> Given it has 3 +1 votes and a result been called it's really up to the >> release manager. IMO it is a blocker, but at the very least I like to see a >> JIRA for it and it fixed for the next release. The LICENSE issues are also >> serious - but hopefully just a misunderstanding to what should go into a >> LICENSE file. >> >> Thanks, >> Justin >> >> >> - >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >> >
Re: [VOTE] Apache Drill 0.4.0-incubating release
Hey guys, Sorry I didn't see Henry and Justin's comments until just now. Per Justin's primary concerns about the License stuff: I think we've just made mistakes in the notice and license files as to exactly how we reference things. All the category B licenses are mvn binary dependencies (per the third party dependencies rules), not source inclusions. To address Justin's concerns, I've created the following JIRAs which we'll fix straight away: DRILL-1274 and DRILL-1275 along with adding additional requirements to DRILL-1271 in addition to Henry's previous notes on NOTICE file. Given the following: - The mistakes are issues with documentation as opposed to invalid source inclusions - The vote was held open for 72 hours before being called - Release artifacts are already on the mirrors - This is a developer preview release with small distribution designed primarily to expand the contributor community - We plan on doing another release within a month where these can be corrected. I'm going to go forward with this release. Thanks again to everyone for all the helpful feedback. I believe we are making good progress. Jacques On Thu, Aug 7, 2014 at 5:44 PM, Justin Mclean wrote: > Hi, > > > Ah, I saw disclaimer in the website [1] which I thought enough for > incubator. > > But checking the branding guide [2] seems like incubator need to > > include DISCLAIMER file along with NOTICE and LICENSE files, so this > > could be blocker? > > Given it has 3 +1 votes and a result been called it's really up to the > release manager. IMO it is a blocker, but at the very least I like to see a > JIRA for it and it fixed for the next release. The LICENSE issues are also > serious - but hopefully just a misunderstanding to what should go into a > LICENSE file. > > Thanks, > Justin > > > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
[RESULT][VOTE] Apache Drill 0.4.0-incubating release
Thanks for all the feedback. I've opened DRILL-1271 to fix the NOTICE issue for the next release. We'll also work towards synchronizing releases. I think it may take a bit of time given how quickly each of these projects are moving. The primary thing we're focused on is making sure that we working with each of the other projects to ensure their integrity and vision. This vote passes with the finally tally: +1 Ted +1 John +1 Henry -1: none Thanks everybody. We'll roll the release to mirrors and move on to the next. Jacques On Wed, Aug 6, 2014 at 4:00 AM, John D. Ament wrote: > +1 binding. > > In the future, I would like to see you guys move to a synchronized release > cycle and only execute releases against their final versions and not > snapshots. Typically, you need to mess with Maven a lot to make this kind > of release even work. > > John > > > On Tue, Aug 5, 2014 at 3:44 PM, Jacques Nadeau wrote: > > > Hey Ted, > > > > Those SNAPSHOT dependencies are a bit misleading. Because Drill is so > > closely coupled to the Optiq and Parquet codebase, we need to generate > > separate artifacts. As part of doing monthly releases, it is unfeasible > to > > bind Drill releases to incorporating of all patches into upstream > projects. > > You can think of this as similar to how, for years, HBase released on > top > > of a modified (non-released) Hadoop due to special requirements for > append. > > > > > > As such, while slightly outside typical maven conventions, those SNAPSHOT > > are fixed and will not change in the future. The github hashes for each > > changeset are as follows: > > > > parquet-format: > > > > > https://github.com/jacques-n/incubator-parquet-format/commit/7001502877e0cfbf81d429656989057ccc5fafb2 > > parquet-mr: > > > > > https://github.com/jaltekruse/parquet-mr/commit/737500cbabd009eee065058fff2ccc8cc806c5b2 > > optiq: > > > > > https://github.com/jacques-n/optiq/commit/4508b617bd3ffed2840055fe16e6684e1c0a35d7 > > > > Hopefully this satisfies the need to document the source references for > > third party dependencies within the Apache Drill 0.4.0 release. > > > > thanks, > > Jacques > > > > > > > > > > On Mon, Aug 4, 2014 at 12:07 PM, Ted Dunning > > wrote: > > > > > I checked the source artifact and found several internal SNAPSHOT > > > dependencies (should be fixed) and one external SNAPSHOT dependency > (must > > > be fixed). > > > > > > The good news is that the external SNAPSHOT dependency is parquet > version > > > 1.5.0-SNAPSHOT. Since parquet 1.5.0 has been released, this should be > a > > > trivial fix. > > > > > > > > > > > > > > > On Mon, Aug 4, 2014 at 8:07 AM, Jacques Nadeau > > wrote: > > > > > > > We've held a vote on drill-dev to release the 0.4.0-incubating > release > > of > > > > Apache Drill. > > > > > > > > The vote thread can be found here: > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201407.mbox/%3CCAKa9qD%3DKQURAMcS3RQJbUABSU4%3DDEGSewK2s4MAAidu4c%3DOjBg%40mail.gmail.com%3E > > > > > > > > The vote passed with: > > > > +6 binding > > > > +7 non-binding > > > > > > > > A summary email can be found here: > > > > > > > > > > > > > > http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201408.mbox/%3CCAKa9qDnyKYS%3D3qbv3%3DfUrcuuNvBKRcvPt4AgWojLhy4tr2ZYLA%40mail.gmail.com%3E > > > > > > > > You can find the artifacts for the release at this location: > > > > http://people.apache.org/~jacques/apache-drill-0.4.0.rc1/ > > > > > > > > Please vote on this release. > > > > > > > > Thanks, > > > > Jacques > > > > > > > > > >
Re: [VOTE] Apache Drill 0.4.0-incubating release
Hey Ted, Those SNAPSHOT dependencies are a bit misleading. Because Drill is so closely coupled to the Optiq and Parquet codebase, we need to generate separate artifacts. As part of doing monthly releases, it is unfeasible to bind Drill releases to incorporating of all patches into upstream projects. You can think of this as similar to how, for years, HBase released on top of a modified (non-released) Hadoop due to special requirements for append. As such, while slightly outside typical maven conventions, those SNAPSHOT are fixed and will not change in the future. The github hashes for each changeset are as follows: parquet-format: https://github.com/jacques-n/incubator-parquet-format/commit/7001502877e0cfbf81d429656989057ccc5fafb2 parquet-mr: https://github.com/jaltekruse/parquet-mr/commit/737500cbabd009eee065058fff2ccc8cc806c5b2 optiq: https://github.com/jacques-n/optiq/commit/4508b617bd3ffed2840055fe16e6684e1c0a35d7 Hopefully this satisfies the need to document the source references for third party dependencies within the Apache Drill 0.4.0 release. thanks, Jacques On Mon, Aug 4, 2014 at 12:07 PM, Ted Dunning wrote: > I checked the source artifact and found several internal SNAPSHOT > dependencies (should be fixed) and one external SNAPSHOT dependency (must > be fixed). > > The good news is that the external SNAPSHOT dependency is parquet version > 1.5.0-SNAPSHOT. Since parquet 1.5.0 has been released, this should be a > trivial fix. > > > > > On Mon, Aug 4, 2014 at 8:07 AM, Jacques Nadeau wrote: > > > We've held a vote on drill-dev to release the 0.4.0-incubating release of > > Apache Drill. > > > > The vote thread can be found here: > > > > > http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201407.mbox/%3CCAKa9qD%3DKQURAMcS3RQJbUABSU4%3DDEGSewK2s4MAAidu4c%3DOjBg%40mail.gmail.com%3E > > > > The vote passed with: > > +6 binding > > +7 non-binding > > > > A summary email can be found here: > > > > > http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201408.mbox/%3CCAKa9qDnyKYS%3D3qbv3%3DfUrcuuNvBKRcvPt4AgWojLhy4tr2ZYLA%40mail.gmail.com%3E > > > > You can find the artifacts for the release at this location: > > http://people.apache.org/~jacques/apache-drill-0.4.0.rc1/ > > > > Please vote on this release. > > > > Thanks, > > Jacques > > >
[VOTE] Apache Drill 0.4.0-incubating release
We've held a vote on drill-dev to release the 0.4.0-incubating release of Apache Drill. The vote thread can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201407.mbox/%3CCAKa9qD%3DKQURAMcS3RQJbUABSU4%3DDEGSewK2s4MAAidu4c%3DOjBg%40mail.gmail.com%3E The vote passed with: +6 binding +7 non-binding A summary email can be found here: http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201408.mbox/%3CCAKa9qDnyKYS%3D3qbv3%3DfUrcuuNvBKRcvPt4AgWojLhy4tr2ZYLA%40mail.gmail.com%3E You can find the artifacts for the release at this location: http://people.apache.org/~jacques/apache-drill-0.4.0.rc1/ Please vote on this release. Thanks, Jacques