Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Craig Russell]

Hi Denis,

Everything looks to be in order. Good luck.

Craig

> On May 22, 2017, at 1:28 PM, Denis Mag  wrote:
> 
> Folks,
> 
> I've just followed well-described and clear "Process" section from this
> page:
> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
> 
> Following 3. GridGain filed SGA that was acknowledged by Craig and recorded
> in grants.txt. Right after that, following 7., this particular discussion
> was kicked off.
> 
> Let me know if something else has to be done to fully comply with the
> donation process. The page below reflects the current status:
> http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html
> 
> 
> 
> --
> View this message in context: 
> http://apache-incubator-general.996316.n3.nabble.com/IP-CLEARANCE-Apache-Ignite-Persistent-Store-tp54969p54999.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
> 

Craig L Russell
c...@apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] [VOTE] Pulsar into the Apache Incubator

[Bryan Call]

Thank you for all that participated in the VOTE.

The VOTE has ended and have this result :

9 +1 binding votes
7 +1 non-binding votes
No 0 votes
No -1 votes

With this Pulsar is officially accepted as Apache incubator project.
Congratulations!

+1 binding tally:
Raphael Bircher
Dave Fisher
Jean-Baptiste Onofré
Jim Jagielski
Phil Sorber
P. Taylor Goetz
Julian Hyde
Mohammad Noureldin
Luke Han

-Bryan

> On May 16, 2017, at 7:39 PM, Bryan Call  wrote:
> 
> Hi All,
> 
> As the champion for Pulsar, I would like to start a VOTE to bring the
> project in as Apache incubator podling.
> 
> The ASF voting rules are described:
> 
>   https://www.apache.org/foundation/voting.html
> 
> A vote for accepting a new Apache Incubator podling is a majority vote for 
> which 
> only Incubator PMC member votes are binding.
> 
> This vote will run for at least 72 hours. Please VOTE as follows
> [] +1 Accept Pulsar into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept Pulsar into the Apache Incubator because ...
> 
> The proposal is listed below, but you can also access it on the wiki:
> 
>   https://wiki.apache.org/incubator/PulsarProposal
> 
> -Bryan
> 
> 
> = Pulsar Proposal =
> 
> == Abstract ==
> 
> Pulsar is a highly scalable, low latency messaging platform running on
> commodity hardware. It provides simple pub-sub semantics over topics,
> guaranteed at-least-once delivery of messages, automatic cursor management for
> subscribers, and cross-datacenter replication.
> 
> == Proposal ==
> 
> Pub-sub messaging is a very common design pattern that is increasingly found
> in distributed systems powering Internet applications. These applications
> provide real-time services, and need publish-latencies of 5ms on average and
> no more than 15ms at the 99th percentile. At Internet scale, these
> applications require a messaging system with ordering, strong durability, and
> delivery guarantees. In order to handle the “five 9’s” durability requirements
> of a production environment, the messages have to be committed on multiple
> disks or nodes.
> 
> Pulsar has been developed at Yahoo to address these specific requirements by
> providing a hosted service supporting millions of topics for multiple tenants.
> The current incarnation of Pulsar has been open-sourced under Apache license
> in September 2016 and it is the direct evolution of systems that were
> developed at Yahoo since 2011.
> 
> We believe there is currently no other system that provides a multi-tenant
> hosted messaging platform capable of supporting a huge number of topics while
> maintaining strict guarantees for durability, ordering and low latency.
> Current solutions would require to run multiple individual clusters with
> additional operational work and capacity overhead.
> 
> Since the open sourcing of Pulsar, the development has been done exclusively
> on the public Github repository and two major releases were shipped (1.15 and
> 1.16), along with multiple minor ones. Several other companies have expressed
> interest in the project and its future direction.
> 
> == Rationale ==
> 
> Pulsar is a platform that is built on top of several other Apache projects. In
> particular, Apache BookKeeper is used to store the data and Apache ZooKeeper
> is used for coordination and metadata storage. Pulsar is also interoperable
> out of the box with Apache Storm, to provide an easy to use stream processing
> solution.
> 
> We want to establish a community outside the scope of initial core developers
> at Yahoo and we believe that the Apache Foundation is a great fit and long-
> term home for Pulsar, as it provides an established process for community-
> driven development and decision making by consensus. This is exactly the model
> we want to adopt for future Pulsar development.
> 
> == Initial Goals ==
> 
> The initial goals will be to move the existing codebase to Apache and
> integrate with the Apache development process. Furthermore, we plan for
> incremental development, and releases along with the Apache guidelines.
> 
> == Current Status ==
> 
> Pulsar has been in service at large scale for more than 2 years at Yahoo. In
> this time around 60 different applications were integrated with Pulsar. Other
> companies are evaluating it as well and have been contributing code to the
> project.
> 
> === Meritocracy ===
> 
> We value meritocracy and we understand that it is the basis to form an open
> community that encourages multiple companies and individuals to contribute and
> get invested in the project future. We will encourage and monitor
> participation and make sure to extend privileges and responsibilities to all
> contributors.
> 
> === Community ===
> 
> We have validated, through the interest demonstrated by Pulsar users at Yahoo,
> that a reliable hosted pub-sub messaging platform represent a very important
> building block for web-scale distributed applications. We believe that many
> companies can benefit by applying the 

Re: Permission to Livy Proposal

[John D. Ament]

Added, happy editing!

On Mon, May 22, 2017 at 5:38 PM Kostas Sakellis  wrote:

> Hello,
>
> Can I please get permission to modify:
> https://wiki.apache.org/incubator/LivyProposal
> My username is: kostas
>
> I'd like to make some edits based on feedback from the Livy Proposal email
> thread.
>
> Thanks,
> Kostas
>

Permission to Livy Proposal

[Kostas Sakellis]

Hello,

Can I please get permission to modify:
https://wiki.apache.org/incubator/LivyProposal
My username is: kostas

I'd like to make some edits based on feedback from the Livy Proposal email
thread.

Thanks,
Kostas

Re: [PROPOSAL] Livy Proposal for Apache Incubator

[Kostas Sakellis]

On Mon, May 22, 2017 at 1:01 AM, Luciano Resende 
wrote:

> +1
>
> Also, I see the proposal is short on mentors, so feel free to include me as
> a mentor for the project.
>
> Thanks
>

Thanks Luciano! Welcome onboard.


> On Fri, May 19, 2017 at 4:45 PM Sean Busbey  wrote:
>
> > Dear Apache Incubator Community,
> >
> > I'm excited to present for discussion a proposal to move Livy into
> > incubation. Livy is web service that exposes a REST interface for
> managing
> > long running Apache Spark contexts in your cluster. With Livy, new
> > applications can be built on top of Apache Spark that require fine
> grained
> > interaction with many Spark contexts.
> >
> > The proposal is on the wiki at the following page as well as copied in
> the
> > email below:
> >
> > https://wiki.apache.org/incubator/LivyProposal
> >
> > In addition to welcoming feedback on the proposal, we are actively
> seeking
> > one or more additional mentors. We also have included a section for
> > interested folks to ensure they get added to the mailing lists, presuming
> > Livy gets accepted for incubation.
> >
> >  LivyProposal
> >
> > = Abstract =
> >
> > Livy is web service that exposes a REST interface for managing
> > long running Apache Spark contexts in your cluster. With Livy, new
> > applications can be built on top of Apache Spark that require fine
> grained
> > interaction with many Spark contexts.
> >
> > = Proposal =
> >
> > Livy is an open-source REST service for Apache Spark. Livy
> > enables applications to submit Spark applications and retrieve results
> > without a co-location requirement on the Spark cluster.
> >
> > We propose to contribute the Livy codebase and associated artifacts (e.g.
> > documentation, web-site context etc) to the Apache Software Foundation.
> >
> > = Background =
> >
> > Apache Spark is a fast and general purpose distributed
> > compute engine, with a versatile API. It enables processing of large
> > quantities of static data distributed over a cluster of machines, as well
> > as
> > processing of continuous streams of data. It is the preferred distributed
> > data processing engine for data engineering, stream processing and data
> > science workloads. Each Spark application uses a construct called the
> > SparkContext, which is the application’s connection or entry point to the
> > Spark engine. Each Spark application will have its own SparkContext.
> >
> > Livy enables clients to interact with one or more Spark sessions through
> > the
> > Livy Server, which acts as a proxy layer. Livy Clients have fine grained
> > control over the lifecycle of the Spark sessions, as well as the ability
> to
> > submit jobs and retrieve results, all over HTTP.  Clients have two modes
> of
> > interaction: RPC Client API, available in Java and Python, which allows
> > results to be retrieved as Java or Python objects. The serialization and
> > deserialization of the results is handled by the Livy framework.  HTTP
> > based
> > API that allows submission of code snippets, and retrieval of the results
> > in
> > different formats.
> >
> > Multi-tenant resource allocation and security: Livy enables multiple
> > independent Spark sessions to be managed simultaneously. Multiple clients
> > can also interact simultaneously with the same Spark session and share
> the
> > resources of that Spark session. Livy can also enforce secure,
> > authenticated
> > communication between the clients and their respective Spark sessions.
> >
> > More information on Livy can be found at the existing open source
> website:
> > http://livy.io/
> >
> > = Rationale =
> >
> > Users want to use Spark’s powerful processing engine and API
> > as the data processing backend for interactive applications. However, the
> > job submission and application interaction mechanisms built into Apache
> > Spark are insufficient and cumbersome for multi-user interactive
> > applications.
> >
> > The primary mechanism for applications to submit Spark jobs is via
> > spark-submit
> > (http://spark.apache.org/docs/latest/submitting-applications.html),
> which
> > is
> > available as a command line tool as well as a programmatic API. However,
> > spark-submit has the following limitations that make it difficult to
> build
> > interactive applications: It is slow: each invocation of spark-submit
> > involves a setup phase where cluster resources are acquired, new
> processes
> > are forked, etc. This setup phase runs for many seconds, or even minutes,
> > and hence is too slow for interactive applications.  It is cumbersome and
> > lacks flexibility: application code and dependencies have to be
> > pre-compiled
> > and submitted as jars, and can not be submitted interactively.
> >
> > Apache Spark comes with an ODBC/JDBC server, which can be used to submit
> > SQL
> > queries to Spark. However, this solution is limited to SQL and does not
> > allow the client to leverage the rest of the Spark API, such as RDDs,

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Denis Magda]

John,

Please see below

** The commit referenced in the IP clearance reflects some changes in a pom 
file.  Is that the only change? **

That’s one of the latest commits happened in that repository. In any case, 
Apache Ignite community decided to push the donation to an Ignite branch:
https://github.com/apache/ignite/tree/ignite-5267 

These are all the changes in compare to the master branch:
https://github.com/apache/ignite/compare/ignite-5267

I’ve updated the IP clearance form to mention this and triggered the 
redeployment of incubator.apache.org. Hope it will appear there soon:
http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html


** In addition, the commit seems to be from Alexey Goncharuk, who is already a 
committer from the foundation (has an ICLA) and is on the PMC for ignite... 
so its not clear why an IP Clearance is needed. **

This is a software grant from GridGain. The grant was filed and acknowledged by 
Craig. Alexey Goncharuk works for GridGain.

—
Denis

> On May 22, 2017, at 1:35 PM, John D. Ament  wrote:
> 
> Denis,
> 
> I raised two questions in my first reply.  Can you respond to them?
> 
> John
> 
> On Mon, May 22, 2017 at 4:28 PM Denis Mag  wrote:
> 
>> Folks,
>> 
>> I've just followed well-described and clear "Process" section from this
>> page:
>> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
>> 
>> Following 3. GridGain filed SGA that was acknowledged by Craig and recorded
>> in grants.txt. Right after that, following 7., this particular discussion
>> was kicked off.
>> 
>> Let me know if something else has to be done to fully comply with the
>> donation process. The page below reflects the current status:
>> 
>> http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html
>> 
>> 
>> 
>> --
>> View this message in context:
>> http://apache-incubator-general.996316.n3.nabble.com/IP-CLEARANCE-Apache-Ignite-Persistent-Store-tp54969p54999.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
>> 
>> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: private list subscriptions

[Sam Ruby]

On Mon, May 22, 2017 at 3:42 PM, Jim Jagielski  wrote:
>
>> On May 22, 2017, at 12:43 PM, sebb  wrote:
>>
>> Whimsy auto-subscribe only allows committers to use their ASF address
>> or the ones listed in thei LDAP record.
>
> That seems, to me, a restriction that Whimsy should fix...
> None of my subscriptions to any private PMC lists that I'm on
> are with my a.o address, and I'm guessing I'm not unique there.

Any email address you add via id.apache.org may be accessed via the
dropdown at https://whimsy.apache.org/committers/subscribe

- Sam Ruby

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[John D. Ament]

Denis,

I raised two questions in my first reply.  Can you respond to them?

John

On Mon, May 22, 2017 at 4:28 PM Denis Mag  wrote:

> Folks,
>
> I've just followed well-described and clear "Process" section from this
> page:
> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
>
> Following 3. GridGain filed SGA that was acknowledged by Craig and recorded
> in grants.txt. Right after that, following 7., this particular discussion
> was kicked off.
>
> Let me know if something else has to be done to fully comply with the
> donation process. The page below reflects the current status:
>
> http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html
>
>
>
> --
> View this message in context:
> http://apache-incubator-general.996316.n3.nabble.com/IP-CLEARANCE-Apache-Ignite-Persistent-Store-tp54969p54999.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: [IP CLEARANCE] Apache Ignite - Persistent Store

[Denis Mag]

Folks,

I've just followed well-described and clear "Process" section from this
page:
http://incubator.apache.org/ip-clearance/ip-clearance-template.html

Following 3. GridGain filed SGA that was acknowledged by Craig and recorded
in grants.txt. Right after that, following 7., this particular discussion
was kicked off.

Let me know if something else has to be done to fully comply with the
donation process. The page below reflects the current status:
http://incubator.apache.org/ip-clearance/persistent-distributed-store-ignite.html



--
View this message in context: 
http://apache-incubator-general.996316.n3.nabble.com/IP-CLEARANCE-Apache-Ignite-Persistent-Store-tp54969p54999.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: [IP CLEARANCE] Apache Ignite - Persistent Store

[Roman Shaposhnik]

On Mon, May 22, 2017 at 1:04 PM, Craig Russell  wrote:
> Hi Niclas,
>
>> On May 22, 2017, at 12:05 AM, Niclas Hedhman  wrote:
>>
>> Originally, the IP Clearance was intended for "block contributions" larger
>> than suitable for a Jira patch file, and from people outside the community.
>> For example, it could be code that was made at SourceForge and IP Clearance
>> was to make sure that the the OK/interest of the authors was recorded (via
>> ICLAs, IIRC).
>>
>> In this case, it seems that the author is on the PM, have an ICLA on file,
>> the work is part of the same commit tree, so I see no reason for the ASF to
>> doubt that he had the permission from the company to commit/push.
>
> My understanding is that the code under review here was developed outside 
> Apache and is larger than suitable for a JIRA patch.
>
> So it is precisely the situation for which IP Clearance is intended.

That's 100% correct!

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Craig Russell]

Hi Niclas,

> On May 22, 2017, at 12:05 AM, Niclas Hedhman  wrote:
> 
> Originally, the IP Clearance was intended for "block contributions" larger
> than suitable for a Jira patch file, and from people outside the community.
> For example, it could be code that was made at SourceForge and IP Clearance
> was to make sure that the the OK/interest of the authors was recorded (via
> ICLAs, IIRC).
> 
> In this case, it seems that the author is on the PM, have an ICLA on file,
> the work is part of the same commit tree, so I see no reason for the ASF to
> doubt that he had the permission from the company to commit/push.

My understanding is that the code under review here was developed outside 
Apache and is larger than suitable for a JIRA patch. 

So it is precisely the situation for which IP Clearance is intended.

Craig
> 
> 
> Cheers
> Niclas
> 
> On Mon, May 22, 2017 at 5:47 AM, Craig Russell  wrote:
> 
>> Let's all read the documentation on IP Clearance so we have a common basis
>> for discussion.
>> 
>> Craig
>> 
>>> On May 21, 2017, at 2:46 PM, Craig Russell  wrote:
>>> 
 
 On May 21, 2017, at 2:02 PM, John D. Ament 
>> wrote:
 
 On Sun, May 21, 2017 at 4:54 PM Craig Russell 
>> wrote:
 
> Hi John,
> 
> I don't know all of the details of the code, but this is in regard to
> GridGain's grant via SGA of a persistent store system which is a
> substantial body of code not developed at Apache. So IMHO it is
>> appropriate
> for the code grant to be reviewed.
> 
> 
 Errr... wait a tick.  We've been told a few times that IP Clearance and
>> SGA
 are binary.  You do one or the other, not both.
>>> 
>>> Reference, please. I recall that IP Clearance is for TLPs to vet large
>> donations.
>>> 
>>> Craig
>>> 
 Specifically SGA is to
 allow the modification of license (from X to Apache-V2.0) whereas IP
 Clearance is verifying that all existing Apache-v2.0 donation is in fact
 properly licensed (e.g. no hidden LGPL or other inappropriate licenses).
 There's even a line in the SGA that puts the ownness on this to the
>> donator.
 
 If GridGain has submitted an SGA then that SGA is what is used.  Have
>> they
 actually submitted an SGA as well?
 
 
 
> I don't see any issues except it's difficult (for me, a git novice) to
> figure out the exact donation. The reference is to a git repository
>> that is
> "194 commits ahead, 240 commits behind apache:master". Most of the
>> donated
> code is in “modules/pds”.
> 
> Craig
> 
>> On May 20, 2017, at 8:53 PM, John D. Ament 
> wrote:
>> 
>> The commit referenced in the IP clearance reflects some changes in a
>> pom
>> file.  Is that the only change?
>> 
>> In addition, the commit seems to be from Alexey Goncharuk, who is
> already a
>> committer from the foundation (has an ICLA) and is on the PMC for
> ignite...
>> so its not clear why an IP Clearance is needed.
>> 
>> John
>> 
>> On Sat, May 20, 2017 at 11:42 PM Denis Magda 
>> wrote:
>> 
>>> Apache Ignite is receiving code for distributed Persistent Store.
>>> 
>>> See:
>>> 
> http://incubator.apache.org/ip-clearance/persistent-
>> distributed-store-ignite.html
>>> 
>>> Please vote to approve the donation.
>>> 
>>> This is a lazy consensus majority vote, open for at least 72 hours.
>>> 
>>> Regards,
>>> Denis
>>> 
>>> 
>>> 
>>> 
>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> 
> 
> Craig L Russell
> c...@apache.org
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>>> 
>>> Craig L Russell
>>> Secretary, Apache Software Foundation
>>> c...@apache.org http://db.apache.org/jdo
>> 
>> Craig L Russell
>> Secretary, Apache Software Foundation
>> c...@apache.org http://db.apache.org/jdo
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 
> 
> 
> -- 
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional 

Re: private list subscriptions

[Jim Jagielski]

> On May 22, 2017, at 12:43 PM, sebb  wrote:
> 
> 
> Whimsy auto-subscribe only allows committers to use their ASF address
> or the ones listed in thei LDAP record.
> 

That seems, to me, a restriction that Whimsy should fix...
None of my subscriptions to any private PMC lists that I'm on
are with my a.o address, and I'm guessing I'm not unique there.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Livy Proposal for Apache Incubator

[John D. Ament]

On Mon, May 22, 2017 at 3:30 PM Sean Busbey  wrote:

> On 2017-05-21 09:46 (-0500), "John D. Ament" 
> wrote:
> >
> > On Fri, May 19, 2017 at 7:45 PM Sean Busbey  wrote:
> > >
> > > == Reliance on salaried Developers ==
> > >
> > > The existing contributors to the Livy project have been made by
> salaried
> > > engineers from Cloudera, Microsoft and Hortonworks. Since there are
> three
> > > major organisations involved, the risk of reliance on a single group of
> > > salaried developers is mitigated. The Livy user base is diverse, with
> users
> > > from across the globe, including users from academic settings. We aim
> to
> > > further diversify the Livy user and contributor base.
> > >
> >
> > There's a disconnect between this paragraph and the initial committers
> > list. Specifically, no one from Microsoft is represented (as best as I
> can
> > tell).
>
> Ah, this lack of clarity is my fault as an editor. One of the initial
> committers was recently employed by Microsoft but is now in the
> process of changing employers. Another person formally affiliated with
> both the project and Microsoft has decided not to continue
> participating.
>
> I could rephrase this to talk about the contributions made to date as
> being from individuals then in the employ of three major companies.
> Then call out the initial committer list as from two of those and one
> unaffiliated. Would that read clearer?
>
>
I think the explanation is enough, nothing to change.


> > > Cloudera currently owns the domain name: http://livy.io/ which will be
> > > transferred to the ASF and redirected to the official page during
> > > incubation.
> > >
> > >
> >
> > I'm assuming that the incoming project is aware that we expect the main
> dev
> > landing page to be livy.incubator.apache.org . We will want to track
> this
> > as a project specific item.
>
>
> Yep, once all the docs are moved over to ASF infrastructure we can
> just have the current domain act as a redirect. Should I call this out
> in the proposal?
>
>
It would be good to list out the goal of moving to livy.i.a.o but not
needed.


>
> > > == Git Repository ==
> > >
> > > git://git.apache.org/livy
> > >
> >
> > Just to confirm - it'll be incubator-livy, not just livy.
>
> right right. I'll correct this when making the other edits.
>
>
> > > == Issue Tracking ==
> > >
> > > We would like to import our current JIRA project into the ASF JIRA,
> such
> > > that our historical commit message and code comments continue to
> reference
> > > the appropriate bug numbers.
> > >
> >
> > I would recommend reaching out to infra to see if the import is possible
> > before voting on the project. Otherwise you'll need to list out an la
>
> Sure I can reach out. I've seen this done a few times, so I consider
> it low risk. The end of your line appears to have been lost, what's
> the "Otherwise..." ?
>
>
Yeah, I'm not sure what happened there either.  I checked my mail client,
E_NOCLUE.

"list out an alternative" is what I was typing.


> > > = Sponsors =
> > > == Champion ==
> > >
> > > * Sean Busbey (bus...@apache.org)
> > >
> > > == Nominated Mentors ==
> > >
> > > * Bikas Saha (bi...@apache.org)
> > > * Brock Noland (br...@phdata.io)
> >
> >
> > A couple of points:
> >
> > - Sean, while the champion and mentor roles are separate, we do hope that
> > all champions will continue on as a mentor. If this is your intention
> > please add yourself.
>
> After having to withdraw from mentoring a couple of podlings at the
> end of last year I am conservative about what my volunteer time looks
> like right now. I'm certain I can spare the time to help the Livy
> community get introduced to the incubator. I'm not certain beyond
> that, so I am not listed as a formal mentor.
>
> >  - All mentors must be on the IPMC. Foundation membership isn't a
> > requirement, however most people use membership to get access to the
> IPMC.
> > If Bikas wants to be a mentor, he'll need to join the IPMC otherwise
> you'll
> > need to find 2 mentors.
>
> I was pretty sure Bikas had already done this step. I'll chase this
> down and find the disconnect.
>
> > - Do the proposed mentors have a relationship to the incoming project,
> e.g.
> > do they care if it succeeds from a corporate interest standpoint?
>
> I'll let the mentors answer for themselves here, as I won't presume to
> know their specific motivations for volunteering.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Livy Proposal for Apache Incubator

[Sean Busbey]

On 2017-05-21 09:46 (-0500), "John D. Ament"  wrote:
>
> On Fri, May 19, 2017 at 7:45 PM Sean Busbey  wrote:
> >
> > == Reliance on salaried Developers ==
> >
> > The existing contributors to the Livy project have been made by salaried
> > engineers from Cloudera, Microsoft and Hortonworks. Since there are three
> > major organisations involved, the risk of reliance on a single group of
> > salaried developers is mitigated. The Livy user base is diverse, with users
> > from across the globe, including users from academic settings. We aim to
> > further diversify the Livy user and contributor base.
> >
>
> There's a disconnect between this paragraph and the initial committers
> list. Specifically, no one from Microsoft is represented (as best as I can
> tell).

Ah, this lack of clarity is my fault as an editor. One of the initial
committers was recently employed by Microsoft but is now in the
process of changing employers. Another person formally affiliated with
both the project and Microsoft has decided not to continue
participating.

I could rephrase this to talk about the contributions made to date as
being from individuals then in the employ of three major companies.
Then call out the initial committer list as from two of those and one
unaffiliated. Would that read clearer?

> > Cloudera currently owns the domain name: http://livy.io/ which will be
> > transferred to the ASF and redirected to the official page during
> > incubation.
> >
> >
>
> I'm assuming that the incoming project is aware that we expect the main dev
> landing page to be livy.incubator.apache.org . We will want to track this
> as a project specific item.


Yep, once all the docs are moved over to ASF infrastructure we can
just have the current domain act as a redirect. Should I call this out
in the proposal?


> > == Git Repository ==
> >
> > git://git.apache.org/livy
> >
>
> Just to confirm - it'll be incubator-livy, not just livy.

right right. I'll correct this when making the other edits.


> > == Issue Tracking ==
> >
> > We would like to import our current JIRA project into the ASF JIRA, such
> > that our historical commit message and code comments continue to reference
> > the appropriate bug numbers.
> >
>
> I would recommend reaching out to infra to see if the import is possible
> before voting on the project. Otherwise you'll need to list out an la

Sure I can reach out. I've seen this done a few times, so I consider
it low risk. The end of your line appears to have been lost, what's
the "Otherwise..." ?

> > = Sponsors =
> > == Champion ==
> >
> > * Sean Busbey (bus...@apache.org)
> >
> > == Nominated Mentors ==
> >
> > * Bikas Saha (bi...@apache.org)
> > * Brock Noland (br...@phdata.io)
>
>
> A couple of points:
>
> - Sean, while the champion and mentor roles are separate, we do hope that
> all champions will continue on as a mentor. If this is your intention
> please add yourself.

After having to withdraw from mentoring a couple of podlings at the
end of last year I am conservative about what my volunteer time looks
like right now. I'm certain I can spare the time to help the Livy
community get introduced to the incubator. I'm not certain beyond
that, so I am not listed as a formal mentor.

>  - All mentors must be on the IPMC. Foundation membership isn't a
> requirement, however most people use membership to get access to the IPMC.
> If Bikas wants to be a mentor, he'll need to join the IPMC otherwise you'll
> need to find 2 mentors.

I was pretty sure Bikas had already done this step. I'll chase this
down and find the disconnect.

> - Do the proposed mentors have a relationship to the incoming project, e.g.
> do they care if it succeeds from a corporate interest standpoint?

I'll let the mentors answer for themselves here, as I won't presume to
know their specific motivations for volunteering.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Livy Proposal for Apache Incubator

[Sean Busbey]

On 2017-05-22 03:01 (-0500), Luciano Resende  wrote:
>  1>
>
> Also, I see the proposal is short on mentors, so feel free to include me as>
> a mentor for the project.>
>
> Thanks>
>


Thanks Luciano! I've added you to the wiki page as a mentor.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Livy Proposal for Apache Incubator

[Jitendra Pandey]

+1

On 5/22/17, 1:01 AM, "Luciano Resende"  wrote:

+1

Also, I see the proposal is short on mentors, so feel free to include me as
a mentor for the project.

Thanks

On Fri, May 19, 2017 at 4:45 PM Sean Busbey  wrote:

> Dear Apache Incubator Community,
>
> I'm excited to present for discussion a proposal to move Livy into
> incubation. Livy is web service that exposes a REST interface for managing
> long running Apache Spark contexts in your cluster. With Livy, new
> applications can be built on top of Apache Spark that require fine grained
> interaction with many Spark contexts.
>
> The proposal is on the wiki at the following page as well as copied in the
> email below:
>
> https://wiki.apache.org/incubator/LivyProposal
>
> In addition to welcoming feedback on the proposal, we are actively seeking
> one or more additional mentors. We also have included a section for
> interested folks to ensure they get added to the mailing lists, presuming
> Livy gets accepted for incubation.
>
>  LivyProposal
>
> = Abstract =
>
> Livy is web service that exposes a REST interface for managing
> long running Apache Spark contexts in your cluster. With Livy, new
> applications can be built on top of Apache Spark that require fine grained
> interaction with many Spark contexts.
>
> = Proposal =
>
> Livy is an open-source REST service for Apache Spark. Livy
> enables applications to submit Spark applications and retrieve results
> without a co-location requirement on the Spark cluster.
>
> We propose to contribute the Livy codebase and associated artifacts (e.g.
> documentation, web-site context etc) to the Apache Software Foundation.
>
> = Background =
>
> Apache Spark is a fast and general purpose distributed
> compute engine, with a versatile API. It enables processing of large
> quantities of static data distributed over a cluster of machines, as well
> as
> processing of continuous streams of data. It is the preferred distributed
> data processing engine for data engineering, stream processing and data
> science workloads. Each Spark application uses a construct called the
> SparkContext, which is the application’s connection or entry point to the
> Spark engine. Each Spark application will have its own SparkContext.
>
> Livy enables clients to interact with one or more Spark sessions through
> the
> Livy Server, which acts as a proxy layer. Livy Clients have fine grained
> control over the lifecycle of the Spark sessions, as well as the ability 
to
> submit jobs and retrieve results, all over HTTP.  Clients have two modes 
of
> interaction: RPC Client API, available in Java and Python, which allows
> results to be retrieved as Java or Python objects. The serialization and
> deserialization of the results is handled by the Livy framework.  HTTP
> based
> API that allows submission of code snippets, and retrieval of the results
> in
> different formats.
>
> Multi-tenant resource allocation and security: Livy enables multiple
> independent Spark sessions to be managed simultaneously. Multiple clients
> can also interact simultaneously with the same Spark session and share the
> resources of that Spark session. Livy can also enforce secure,
> authenticated
> communication between the clients and their respective Spark sessions.
>
> More information on Livy can be found at the existing open source website:
> http://livy.io/
>
> = Rationale =
>
> Users want to use Spark’s powerful processing engine and API
> as the data processing backend for interactive applications. However, the
> job submission and application interaction mechanisms built into Apache
> Spark are insufficient and cumbersome for multi-user interactive
> applications.
>
> The primary mechanism for applications to submit Spark jobs is via
> spark-submit
> (http://spark.apache.org/docs/latest/submitting-applications.html), which
> is
> available as a command line tool as well as a programmatic API. However,
> spark-submit has the following limitations that make it difficult to build
> interactive applications: It is slow: each invocation of spark-submit
> involves a setup phase where cluster resources are acquired, new processes
> are forked, etc. This setup phase runs for many seconds, or even minutes,
> and hence is too slow for interactive applications.  It is cumbersome and
> lacks flexibility: application code and dependencies have to be
> pre-compiled
> and submitted as jars, and can not be submitted interactively.
>
> Apache Spark comes with an ODBC/JDBC server, which can be used to submit
> SQL
  

Re: private list subscriptions

[sebb]

On 22 May 2017 at 12:58, Jim Jagielski  wrote:
> I don't think it matters... People use their @a.o emails for
> various reasons, as well as NOT use them for various reasons.
> I don't think we should 2nd guess or, even worse, intrude on
> people's ind. email practices, IMO.
>
>> On May 20, 2017, at 7:05 PM, Henri Yandell  wrote:
>>
>> Dumb question time.
>>
>> Should we encourage that @apache.org addresses are used when subscribing to
>> a private PMC list; and if not all PMC members have subscribed on a
>> podling, can one subscribe their @apache.org addresses for them?
>>
>> Or should we mandate that @apache are used?
>>
>> Does anything automatic happen that ensures that only committers'
>> addresses, or one of their preferred alternative addresses, are being used?
>> I'm suspecting not.

Whimsy auto-subscribe only allows committers to use their ASF address
or the ones listed in thei LDAP record.

For manual moderation, I assume that moderators will check that the
address belongs to valid account somehow.

There may be other ways for moderators to ascertain that an address
which is not in LDAP is nevertheless valid.


>> Thanks,
>>
>> Hen
>
>
> -
> 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

[jira] [Closed] (INCUBATOR-128) Wrong email address in sample PPMC invitation email

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed INCUBATOR-128.
---
Resolution: Fixed

> Wrong email address in sample PPMC invitation email
> ---
>
> Key: INCUBATOR-128
> URL: https://issues.apache.org/jira/browse/INCUBATOR-128
> Project: Incubator
>  Issue Type: Bug
>Reporter: Julian Hyde
>
> The sample invitation email http://incubator.apache.org/guides/ppmc-offer.txt 
> is very useful (thank you!). But the sample email address should be 
> private-subscr...@frizzle.incubator.apache.org and not 
> frizzle-private-subscr...@incubator.apache.org since that is the style for 
> mailing lists these days.
> It's a minor point, but it wasted a couple of hours of a few people's time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: private list subscriptions

[Jim Jagielski]

I don't think it matters... People use their @a.o emails for
various reasons, as well as NOT use them for various reasons.
I don't think we should 2nd guess or, even worse, intrude on
people's ind. email practices, IMO.

> On May 20, 2017, at 7:05 PM, Henri Yandell  wrote:
> 
> Dumb question time.
> 
> Should we encourage that @apache.org addresses are used when subscribing to
> a private PMC list; and if not all PMC members have subscribed on a
> podling, can one subscribe their @apache.org addresses for them?
> 
> Or should we mandate that @apache are used?
> 
> Does anything automatic happen that ensures that only committers'
> addresses, or one of their preferred alternative addresses, are being used?
> I'm suspecting not.
> 
> Thanks,
> 
> Hen


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Commented] (INCUBATOR-198) clean up archive.a.o

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16019365#comment-16019365
 ] 

Sebb commented on INCUBATOR-198:


It does not seem right to delete any archives that were correctly published 
originally.

I think the only reason should be an inadvertent publication (which would 
normally have been done at the time) or perhaps a take-down notice.

> clean up archive.a.o
> 
>
> Key: INCUBATOR-198
> URL: https://issues.apache.org/jira/browse/INCUBATOR-198
> Project: Incubator
>  Issue Type: Task
>Reporter: Greg Stein
>Priority: Minor
>
> The Incubator area at https://archive.apache.org/dist/incubator/ contains 
> historical release artifacts for many projects that are no longer in the 
> Incubator. I believe these need to be managed in some way. For example:
> * any podling that graduated should have its archive.a.o assets moved to 
> their current TLP archive directory
> * the above would include those who may be in the Attic now. we do not change 
> their release archive when they enter the Attic
> * for podlings that were retired, we should delete any artifacts from our 
> archive since they are not ASF artifacts
> This is an Incubator policy issue, along with the many TLPs who had 
> incubator-based releases. Infra can/will move any files as appropriate, but 
> we need instructions from the stakeholders.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Commented] (INCUBATOR-130) Nuvem in limbo

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16019350#comment-16019350
 ] 

Sebb commented on INCUBATOR-130:


Tuscany has since moved to the Attic

> Nuvem in limbo
> --
>
> Key: INCUBATOR-130
> URL: https://issues.apache.org/jira/browse/INCUBATOR-130
> Project: Incubator
>  Issue Type: Bug
>Reporter: Sebb
>
> The Nuvem podling appears to be in limbo.
> According to podling.xml it graduated, but the comment says:
> "The podling was voted to become part of Tuscany in Nov 2012 but (as of Aug 
> 2014) nothing has happened."
> The SVN tree still exists.
> Either the graduation should be completed or the podling should be retired.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Commented] (INCUBATOR-127) Project name still shows as Apache Argus - It should be Apache Ranger.

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16019347#comment-16019347
 ] 

Sebb commented on INCUBATOR-127:


Podling has graduated - it looks as though the renames were done

> Project name still shows as Apache Argus - It should be Apache Ranger.
> --
>
> Key: INCUBATOR-127
> URL: https://issues.apache.org/jira/browse/INCUBATOR-127
> Project: Incubator
>  Issue Type: Bug
>  Components: site
>Reporter: Selvamohan Neethiraj
>
> Project name in Apache Incubator site is still showing up as Argus (after it 
> got renamed as Ranger)
> http://incubator.apache.org/
>- In the List of all current Incubator projects



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Commented] (INCUBATOR-128) Wrong email address in sample PPMC invitation email

[Sebb (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16019341#comment-16019341
 ] 

Sebb commented on INCUBATOR-128:


This has been fixed; the issue can be closed

> Wrong email address in sample PPMC invitation email
> ---
>
> Key: INCUBATOR-128
> URL: https://issues.apache.org/jira/browse/INCUBATOR-128
> Project: Incubator
>  Issue Type: Bug
>Reporter: Julian Hyde
>
> The sample invitation email http://incubator.apache.org/guides/ppmc-offer.txt 
> is very useful (thank you!). But the sample email address should be 
> private-subscr...@frizzle.incubator.apache.org and not 
> frizzle-private-subscr...@incubator.apache.org since that is the style for 
> mailing lists these days.
> It's a minor point, but it wasted a couple of hours of a few people's time.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Created] (INCUBATOR-199) Extend podlings.xml to include old names and TLP parent

[Sebb (JIRA)]

Sebb created INCUBATOR-199:
--

 Summary: Extend podlings.xml to include old names and TLP parent
 Key: INCUBATOR-199
 URL: https://issues.apache.org/jira/browse/INCUBATOR-199
 Project: Incubator
  Issue Type: New Feature
Reporter: Sebb


Podling names change fairly often.
It would be useful to be able to list old names in the podlings file.
At present this info is only in the free-form text.

Also where a podling graduates as a project of a PMC, it would be useful to be 
able to document the PMC. At present this would have to be extracted from the 
url field (or the text)

AFAIK additional attributes do not cause problems for existing parsing 
routines. However the DTD will have to be extended to allow for the new entries.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Livy Proposal for Apache Incubator

[Luciano Resende]

+1

Also, I see the proposal is short on mentors, so feel free to include me as
a mentor for the project.

Thanks

On Fri, May 19, 2017 at 4:45 PM Sean Busbey  wrote:

> Dear Apache Incubator Community,
>
> I'm excited to present for discussion a proposal to move Livy into
> incubation. Livy is web service that exposes a REST interface for managing
> long running Apache Spark contexts in your cluster. With Livy, new
> applications can be built on top of Apache Spark that require fine grained
> interaction with many Spark contexts.
>
> The proposal is on the wiki at the following page as well as copied in the
> email below:
>
> https://wiki.apache.org/incubator/LivyProposal
>
> In addition to welcoming feedback on the proposal, we are actively seeking
> one or more additional mentors. We also have included a section for
> interested folks to ensure they get added to the mailing lists, presuming
> Livy gets accepted for incubation.
>
>  LivyProposal
>
> = Abstract =
>
> Livy is web service that exposes a REST interface for managing
> long running Apache Spark contexts in your cluster. With Livy, new
> applications can be built on top of Apache Spark that require fine grained
> interaction with many Spark contexts.
>
> = Proposal =
>
> Livy is an open-source REST service for Apache Spark. Livy
> enables applications to submit Spark applications and retrieve results
> without a co-location requirement on the Spark cluster.
>
> We propose to contribute the Livy codebase and associated artifacts (e.g.
> documentation, web-site context etc) to the Apache Software Foundation.
>
> = Background =
>
> Apache Spark is a fast and general purpose distributed
> compute engine, with a versatile API. It enables processing of large
> quantities of static data distributed over a cluster of machines, as well
> as
> processing of continuous streams of data. It is the preferred distributed
> data processing engine for data engineering, stream processing and data
> science workloads. Each Spark application uses a construct called the
> SparkContext, which is the application’s connection or entry point to the
> Spark engine. Each Spark application will have its own SparkContext.
>
> Livy enables clients to interact with one or more Spark sessions through
> the
> Livy Server, which acts as a proxy layer. Livy Clients have fine grained
> control over the lifecycle of the Spark sessions, as well as the ability to
> submit jobs and retrieve results, all over HTTP.  Clients have two modes of
> interaction: RPC Client API, available in Java and Python, which allows
> results to be retrieved as Java or Python objects. The serialization and
> deserialization of the results is handled by the Livy framework.  HTTP
> based
> API that allows submission of code snippets, and retrieval of the results
> in
> different formats.
>
> Multi-tenant resource allocation and security: Livy enables multiple
> independent Spark sessions to be managed simultaneously. Multiple clients
> can also interact simultaneously with the same Spark session and share the
> resources of that Spark session. Livy can also enforce secure,
> authenticated
> communication between the clients and their respective Spark sessions.
>
> More information on Livy can be found at the existing open source website:
> http://livy.io/
>
> = Rationale =
>
> Users want to use Spark’s powerful processing engine and API
> as the data processing backend for interactive applications. However, the
> job submission and application interaction mechanisms built into Apache
> Spark are insufficient and cumbersome for multi-user interactive
> applications.
>
> The primary mechanism for applications to submit Spark jobs is via
> spark-submit
> (http://spark.apache.org/docs/latest/submitting-applications.html), which
> is
> available as a command line tool as well as a programmatic API. However,
> spark-submit has the following limitations that make it difficult to build
> interactive applications: It is slow: each invocation of spark-submit
> involves a setup phase where cluster resources are acquired, new processes
> are forked, etc. This setup phase runs for many seconds, or even minutes,
> and hence is too slow for interactive applications.  It is cumbersome and
> lacks flexibility: application code and dependencies have to be
> pre-compiled
> and submitted as jars, and can not be submitted interactively.
>
> Apache Spark comes with an ODBC/JDBC server, which can be used to submit
> SQL
> queries to Spark. However, this solution is limited to SQL and does not
> allow the client to leverage the rest of the Spark API, such as RDDs, MLlib
> and Streaming.
>
> A third way of using Spark is via its command-line shell, which allows the
> interactive submission of snippets of Spark code. However, the shell
> entails
> running Spark code on the client machine and hence is not a viable
> mechanism
> for remote clients to submit Spark jobs.
>
> Livy solves the limitations of the 

Re: [IP CLEARANCE] Apache Ignite - Persistent Store

[Niclas Hedhman]

Originally, the IP Clearance was intended for "block contributions" larger
than suitable for a Jira patch file, and from people outside the community.
For example, it could be code that was made at SourceForge and IP Clearance
was to make sure that the the OK/interest of the authors was recorded (via
ICLAs, IIRC).

In this case, it seems that the author is on the PM, have an ICLA on file,
the work is part of the same commit tree, so I see no reason for the ASF to
doubt that he had the permission from the company to commit/push.


Cheers
Niclas

On Mon, May 22, 2017 at 5:47 AM, Craig Russell  wrote:

> Let's all read the documentation on IP Clearance so we have a common basis
> for discussion.
>
> Craig
>
> > On May 21, 2017, at 2:46 PM, Craig Russell  wrote:
> >
> >>
> >> On May 21, 2017, at 2:02 PM, John D. Ament 
> wrote:
> >>
> >> On Sun, May 21, 2017 at 4:54 PM Craig Russell 
> wrote:
> >>
> >>> Hi John,
> >>>
> >>> I don't know all of the details of the code, but this is in regard to
> >>> GridGain's grant via SGA of a persistent store system which is a
> >>> substantial body of code not developed at Apache. So IMHO it is
> appropriate
> >>> for the code grant to be reviewed.
> >>>
> >>>
> >> Errr... wait a tick.  We've been told a few times that IP Clearance and
> SGA
> >> are binary.  You do one or the other, not both.
> >
> > Reference, please. I recall that IP Clearance is for TLPs to vet large
> donations.
> >
> > Craig
> >
> >> Specifically SGA is to
> >> allow the modification of license (from X to Apache-V2.0) whereas IP
> >> Clearance is verifying that all existing Apache-v2.0 donation is in fact
> >> properly licensed (e.g. no hidden LGPL or other inappropriate licenses).
> >> There's even a line in the SGA that puts the ownness on this to the
> donator.
> >>
> >> If GridGain has submitted an SGA then that SGA is what is used.  Have
> they
> >> actually submitted an SGA as well?
> >>
> >>
> >>
> >>> I don't see any issues except it's difficult (for me, a git novice) to
> >>> figure out the exact donation. The reference is to a git repository
> that is
> >>> "194 commits ahead, 240 commits behind apache:master". Most of the
> donated
> >>> code is in “modules/pds”.
> >>>
> >>> Craig
> >>>
>  On May 20, 2017, at 8:53 PM, John D. Ament 
> >>> wrote:
> 
>  The commit referenced in the IP clearance reflects some changes in a
> pom
>  file.  Is that the only change?
> 
>  In addition, the commit seems to be from Alexey Goncharuk, who is
> >>> already a
>  committer from the foundation (has an ICLA) and is on the PMC for
> >>> ignite...
>  so its not clear why an IP Clearance is needed.
> 
>  John
> 
>  On Sat, May 20, 2017 at 11:42 PM Denis Magda 
> wrote:
> 
> > Apache Ignite is receiving code for distributed Persistent Store.
> >
> > See:
> >
> >>> http://incubator.apache.org/ip-clearance/persistent-
> distributed-store-ignite.html
> >
> > Please vote to approve the donation.
> >
> > This is a lazy consensus majority vote, open for at least 72 hours.
> >
> > Regards,
> > Denis
> >
> >
> >
> > 
> -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
> >>>
> >>> Craig L Russell
> >>> c...@apache.org
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >>> For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > c...@apache.org http://db.apache.org/jdo
>
> Craig L Russell
> Secretary, Apache Software Foundation
> c...@apache.org http://db.apache.org/jdo
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Niclas Hedhman, Software Developer
http://polygene.apache.org - New Energy for Java