Re: [VOTE] Accept XTable into the ASF Incubator

[Jacques Nadeau]

+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

[Jacques Nadeau]

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
> 

Re: [DISCUSS] OneTable proposal

[Jacques Nadeau]

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

[Jacques Nadeau]

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

[Jacques Nadeau]

+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

[Jacques Nadeau]

+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

[Jacques Nadeau]

+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

[Jacques Nadeau]

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

[Jacques Nadeau]

criptions)
>  * d...@heron.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

[Jacques Nadeau]

+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.
> 

Re: [VOTE] Bring Griffin to Apache Incubator

[Jacques Nadeau]

+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

Re: [RESULT][VOTE] Apache CarbonData 0.2.0-incubating release

[Jacques Nadeau]

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

[Jacques Nadeau]

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

[Jacques Nadeau]

+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. 

Re: [VOTE] Accept Airflow into the Incubator

[Jacques Nadeau]

+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 

Re: [VOTE] Accept Mnemonic into the Apache Incubator

[Jacques Nadeau]

+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 

Re: [DISCUSS] Mnemonic incubator proposal

[Jacques Nadeau]

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 

Re: FW: [DISCUSSION] How to deal with runtime dependencies

[Jacques Nadeau]

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

[Jacques Nadeau]

+1 binding -  Jacques Nadeau
On Feb 2, 2016 8:11 PM, "Greg Trasuk" <tras...@stratuscom.com> wrote:

>
> +1 (Binding) - Greg Trasuk
>
>
> > On Feb 2, 2016, at 10:05 AM, Jean-Baptiste Onofré <j...@nanthrax.net>
> 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

Re: [VOTE] Release Apache Myriad 0.1.0 (incubating)

[Jacques Nadeau]

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

[Jacques Nadeau]

+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

[Jacques Nadeau]

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

[Jacques Nadeau]

+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: [ANNOUNCE] Six new Incubator PMC members

[Jacques Nadeau]

Thanks! Looking forward to helping out in new ways.

On Fri, Nov 6, 2015 at 9:57 PM, Henry Saputra <henry.sapu...@gmail.com>
wrote:

> Welcome!
>
> On Fri, Nov 6, 2015 at 8:43 PM, Marvin Humphrey <mar...@rectangular.com>
> 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

[Jacques Nadeau]

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

[Jacques Nadeau]

+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

[Jacques Nadeau]

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 <hashut...@apache.org>
wrote:

> Forwarding my +1 from Calcite list.
>
> Ashutosh
>
> On Mon, Aug 31, 2015 at 10:59 AM, Alan Gates <alanfga...@gmail.com> wrote:
>
>> Forwarding my +1 from the Calcite vote.
>>
>> Alan.
>>
>> Jacques Nadeau <jacq...@apache.org>
>> 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

[Jacques Nadeau]

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 jus...@classsoftware.com
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

[VOTE] Release apache-calcite-1.4.0-incubating

[Jacques Nadeau]

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

[Jacques Nadeau]

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 mar...@rectangular.com
wrote:

 On Fri, Aug 28, 2015 at 2:32 PM, Jacques Nadeau jacq...@apache.org
 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

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Jacques Nadeau]

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 ted.dunn...@gmail.com wrote:

 On Tue, Oct 14, 2014 at 7:24 AM, sebb seb...@gmail.com 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

[Jacques Nadeau]

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

[Jacques Nadeau]

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 seb...@gmail.com wrote:

 On 9 September 2014 13:24, jan i j...@apache.org wrote:
  On 9 September 2014 06:51, Ted Dunning ted.dunn...@gmail.com 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 john.d.am...@gmail.com
  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 ted.dunn...@gmail.com
  wrote:
  
Is the new process documented somewhere?
   
   
   
   
On Mon, Sep 8, 2014 at 3:17 PM, sebb seb...@gmail.com wrote:
   
 On 7 September 2014 20:31, Jacques Nadeau jacq...@apache.org
  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
 transfer the files from dev to release area.
 This provides traceability (assuming the the release vote includes
  the
 SVN revision number)

  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 
   john.d.am...@gmail.com

  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 
  jacq...@apache.org
   
  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

Re: [VOTE] Apache Drill 0.5.0-incubating release

[Jacques Nadeau]

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 john.d.am...@gmail.com
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 jacq...@apache.org
 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
 

Re: [VOTE] Apache Drill 0.5.0-incubating release

[Jacques Nadeau]

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 john.d.am...@gmail.com
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 jacq...@apache.org
 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 john.d.am...@gmail.com
  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 jacq...@apache.org
   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

Re: [VOTE] Apache Drill 0.5.0-incubating release

[Jacques Nadeau]

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 john.d.am...@gmail.com
wrote:

 On Sun, Sep 7, 2014 at 3:39 PM, jan i j...@apache.org wrote:

  On 7 September 2014 21:31, Jacques Nadeau jacq...@apache.org 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 john.d.am...@gmail.com
 
   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 jacq...@apache.org
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

[VOTE] Apache Drill 0.5.0-incubating release

[Jacques Nadeau]

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

[Jacques Nadeau]

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 jus...@classsoftware.com
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

[Jacques Nadeau]

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 jacq...@apache.org 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 jus...@classsoftware.com
 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

[Jacques Nadeau]

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 john.d.am...@gmail.com
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 jacq...@apache.org 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 ted.dunn...@gmail.com
  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 jacq...@apache.org
  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

[Jacques Nadeau]

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 ted.dunn...@gmail.com 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 jacq...@apache.org 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

[Jacques Nadeau]

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