date:20160229

RE: Copyright sign offs

2016-02-29 Thread Dennis E. Hamilton

> -Original Message-
> From: Henri Yandell [mailto:bay...@apache.org]
> Sent: Monday, February 29, 2016 18:43
> To: general@incubator.apache.org
> Cc: Dennis Hamilton 
> Subject: Re: Copyright sign offs
> 
> Is 'it was already under Apache 2.0' typically taken to cover:
> 
>   "Check and make sure that the papers that transfer rights to the ASF
> been
> received. It is only necessary to transfer rights for the package, the
> core
> code, and any new code produced by the project."
> 
> ?
[orcmid] 

No, I don't take it to cover that.  I think it is more like speaking of 
third-party code that bears ALv2 license notices already.

[Also "rights" and "transfer" are rather vague and potentially over-broad.  I 
have no interest in haggling about that.  All I am suggesting is that the 
original files do not appear to be transposed to having the form of notice 
preferred by the ASF.  Having not been on the PPMC, I have no idea what grants 
were received in any form.] 

> 
> Hen
> 
> 
> 
> On Mon, Feb 29, 2016 at 4:17 PM, John D. Ament 
> wrote:
> 
> > Dennis,
> >
> > For some reason, Oliver Rau added you in this commit
> >
> >
> https://svn.apache.org/viewvc/incubator/public/trunk/content/projects/od
> ftoolkit.xml?r1=1296007=1531246
> > If you don't belong, you should be able to remove yourself.
> >
> > John
> >
> > On Mon, Feb 29, 2016 at 6:30 PM Dennis E. Hamilton <
> > dennis.hamil...@acm.org>
> > wrote:
> >
> > > Henri,
> > >
> > > I did a quick look at the odftoolkit repository and the podling
> page.
> > >
> > > The odftoolkit project was originally under ALv2.  The code still
> carries
> > > Copyright notices on the individual files and the ALv2 license
> statement
> > > has not been updated/replaced by the current one mentioning
> contribution
> > to
> > > the ASF, etc.
> > >
> > > In passing, I notice a peculiarity of the incubator page,
> > > .  I'm certain
> I
> > > was never on the PPMC and I don't think I was a committer either,
> unless
> > it
> > > is transitive via incubator (a change since 2012?).  My impression
> was
> > that
> > > the PPMC was rather small.  I have no idea what its current
> membership
> > is.
> > >
> > > There has been recent maintenance on the source code, some working
> > against
> > > JIRA issues, as reported in the February 2016 Incubator Report.
> > >
> > >  - Dennis
> > >
> > >
> > > > -Original Message-
> > > > From: Henri Yandell [mailto:bay...@apache.org]
> > > > Sent: Friday, February 26, 2016 17:28
> > > > To: general@incubator.apache.org
> > > > Subject: Copyright sign offs
> > > >
> > > > Haven't done this in a while :)
> > > >
> > > > Thought I'd share that the following podlings have not yet signed
> off
> > on
> > > > their Copyright sections in their status reports. I mention this
> > because
> > > > I
> > > > believe it's one of the first elements that should be signed off
> on the
> > > > status report and it's a worry if projects have not done so:
> > > >
> > > >   cmda
> > > >   datafu
> > > >   horn
> > > >   johnzon
> > > >   odftoolkit
> > > [ ... ]
> > > >
> > > > I'd be interested to hear about any reasons why the above aren't
> able
> > to
> > > > sign that element of their status file off.
> > > [ ... ]
> > >
> > >
> > > 
> -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >


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

Re: [VOTE] Apache Apex Malhar Release 3.3.1-incubating (RC1)

2016-02-29 Thread Hitesh Shah

+1 - carried over from dev list (binding)

thanks
— Hitesh


On Feb 28, 2016, at 9:53 AM, Bhupesh Chawda  wrote:

> Hi,
> 
> Please vote on the following Apache Apex Malhar 3.3.1-incubating release
> candidate.
> 
> The Apache Apex PPMC has voted to release this candidate.
> 
> The community vote passed with 4 binding votes. There were another 3
> committer votes in favor of the release.
> 
> PPMC vote call:
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAHvM9d2ZWZAvyhZcWGsKQBQHc_O%2BbC%2BexnppXU8FYyjiWsL8PA%40mail.gmail.com%3E
> 
> PPMC vote result:
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAHvM9d01_jUQhtQPSGj11dwWwUqUg2dBfMwKjuxDL2EHBUizRg%40mail.gmail.com%3E
> 
> This is a source release with binary artifacts published to Maven.
> 
> List of all issues fixed: https://s.apache.org/E2rj
> 
> Staging directory:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/
> Source zip:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/malhar-3.3.1-incubating-source-release.zip
> Source tar.gz:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/malhar-3.3.1-incubating-source-release.tar.gz
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheapex-1008
> 
> Git source:
> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.3.1-incubating-RC1
> (commit: a2a3a0f976f153c6bda83586f6f4df01b596c616)
> 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=vindex=bhup...@apache.org
> KEYS file:
> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
> 
> More information at:
> http://apex.incubator.apache.org
> 
> Please try the release and vote; vote will be open for at least 72 hours.
> 
> Thanks,
> Bhupesh


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

Re: Trouble building the incbuator website [ERR 0194]

2016-02-29 Thread Henri Yandell

On Mon, Feb 29, 2016 at 6:26 PM, Marvin Humphrey 
wrote:

> On Mon, Feb 29, 2016 at 5:44 PM, Katherine Marsden 
> wrote:
> > On 2/29/2016 5:10 PM, Katherine Marsden wrote:
> >>
> >> Hi,
> >>
> >> I am having trouble building the incubator website.   I am working on
> >> Windows 7 using Cygwin, but see the same error with git-bash.
> >> I am using IBM java 8
> >>
> > I guess IBM java was the issue. I can build using Oracle java for my
> > JAVA_HOME
>
> Glad you were able to make it work, and thank you for following up
> with the workaround!
>

As a guess, by comparing to the Attic site; maybe you need to drop a
xerces/xalan jar pair into lib.

http://svn.apache.org/repos/asf/attic/site/

Just in case anyone else hits this and finds this email.

Hen

Re: Copyright sign offs

2016-02-29 Thread Henri Yandell

Is 'it was already under Apache 2.0' typically taken to cover:

  "Check and make sure that the papers that transfer rights to the ASF been
received. It is only necessary to transfer rights for the package, the core
code, and any new code produced by the project."

?

Hen



On Mon, Feb 29, 2016 at 4:17 PM, John D. Ament 
wrote:

> Dennis,
>
> For some reason, Oliver Rau added you in this commit
>
> https://svn.apache.org/viewvc/incubator/public/trunk/content/projects/odftoolkit.xml?r1=1296007=1531246
> If you don't belong, you should be able to remove yourself.
>
> John
>
> On Mon, Feb 29, 2016 at 6:30 PM Dennis E. Hamilton <
> dennis.hamil...@acm.org>
> wrote:
>
> > Henri,
> >
> > I did a quick look at the odftoolkit repository and the podling page.
> >
> > The odftoolkit project was originally under ALv2.  The code still carries
> > Copyright notices on the individual files and the ALv2 license statement
> > has not been updated/replaced by the current one mentioning contribution
> to
> > the ASF, etc.
> >
> > In passing, I notice a peculiarity of the incubator page,
> > .  I'm certain I
> > was never on the PPMC and I don't think I was a committer either, unless
> it
> > is transitive via incubator (a change since 2012?).  My impression was
> that
> > the PPMC was rather small.  I have no idea what its current membership
> is.
> >
> > There has been recent maintenance on the source code, some working
> against
> > JIRA issues, as reported in the February 2016 Incubator Report.
> >
> >  - Dennis
> >
> >
> > > -Original Message-
> > > From: Henri Yandell [mailto:bay...@apache.org]
> > > Sent: Friday, February 26, 2016 17:28
> > > To: general@incubator.apache.org
> > > Subject: Copyright sign offs
> > >
> > > Haven't done this in a while :)
> > >
> > > Thought I'd share that the following podlings have not yet signed off
> on
> > > their Copyright sections in their status reports. I mention this
> because
> > > I
> > > believe it's one of the first elements that should be signed off on the
> > > status report and it's a worry if projects have not done so:
> > >
> > >   cmda
> > >   datafu
> > >   horn
> > >   johnzon
> > >   odftoolkit
> > [ ... ]
> > >
> > > I'd be interested to hear about any reasons why the above aren't able
> to
> > > sign that element of their status file off.
> > [ ... ]
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Trouble building the incbuator website [ERR 0194]

2016-02-29 Thread Marvin Humphrey

On Mon, Feb 29, 2016 at 5:44 PM, Katherine Marsden  wrote:
> On 2/29/2016 5:10 PM, Katherine Marsden wrote:
>>
>> Hi,
>>
>> I am having trouble building the incubator website.   I am working on
>> Windows 7 using Cygwin, but see the same error with git-bash.
>> I am using IBM java 8
>>
> I guess IBM java was the issue. I can build using Oracle java for my
> JAVA_HOME

Glad you were able to make it work, and thank you for following up
with the workaround!

Marvin Humphrey

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

Re: [VOTE] Apache Apex Malhar Release 3.3.1-incubating (RC1)

2016-02-29 Thread Vlad Rozov


+1.

- Verified signatures
- Verified hashes/checksums
- Checked DISCLAIMER, LICENSE, NOTICE
- Apache rat and license check pass
- Maven build and unit tests run clean

Thank you,

Vlad

On 2/28/16 09:53, Bhupesh Chawda wrote:

Hi,

Please vote on the following Apache Apex Malhar 3.3.1-incubating release
candidate.

The Apache Apex PPMC has voted to release this candidate.

The community vote passed with 4 binding votes. There were another 3
committer votes in favor of the release.

PPMC vote call:
http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAHvM9d2ZWZAvyhZcWGsKQBQHc_O%2BbC%2BexnppXU8FYyjiWsL8PA%40mail.gmail.com%3E

PPMC vote result:
http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAHvM9d01_jUQhtQPSGj11dwWwUqUg2dBfMwKjuxDL2EHBUizRg%40mail.gmail.com%3E

This is a source release with binary artifacts published to Maven.

List of all issues fixed: https://s.apache.org/E2rj

Staging directory:
https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/
Source zip:
https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/malhar-3.3.1-incubating-source-release.zip
Source tar.gz:
https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/malhar-3.3.1-incubating-source-release.tar.gz
Maven staging repository:
https://repository.apache.org/content/repositories/orgapacheapex-1008

Git source:
https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.3.1-incubating-RC1
  (commit: a2a3a0f976f153c6bda83586f6f4df01b596c616)

PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=vindex=bhup...@apache.org
KEYS file:
https://dist.apache.org/repos/dist/release/incubator/apex/KEYS

More information at:
http://apex.incubator.apache.org

Please try the release and vote; vote will be open for at least 72 hours.

Thanks,
Bhupesh




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

Re: Trouble building the incbuator website [ERR 0194]

2016-02-29 Thread Katherine Marsden


On 2/29/2016 5:10 PM, Katherine Marsden wrote:

Hi,

I am having trouble building the incubator website.   I am working on 
Windows 7 using Cygwin, but see the same error with git-bash.

I am using IBM java 8

I guess IBM java was the issue. I can build using Oracle java for my 
JAVA_HOME



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

Re: [VOTE] Release of Apache MRQL 0.9.6 incubating (RC1)

2016-02-29 Thread Justin Mclean

Hi,

+1 binding

I checked:
- signatures and hashes good
- incubating in name
- DISCLAIMER exists
- LICENSE and NOTICE all good / nice and simple
- All source files have headers except for a few JS files
- No binaries in source release
- Can compile from source

I also checked the binary release (including contents of jars) and it’s also 
perfect..

Only one tiny thing you may want to consider signing the releases with an 
apache email address.

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

Trouble building the incbuator website [ERR 0194]

2016-02-29 Thread Katherine Marsden


Hi,

I am having trouble building the incubator website.   I am working on 
Windows 7 using Cygwin, but see the same error with git-bash.

I am using IBM java 8


 [xslt] : Fatal Error! [ERR 0194] The 
javax.xml.transform.stream.StreamResult associated with the 
xsl:result-documen
t with href 'target/current.ent' and base output URI 
'file:/C:/Cygwin/svn/incubator/trunk/target/index.tmp' has neither

its Writer nor its OutputStream set.
 [xslt] : Fatal Error! [ERR 0629] A redirect instruction failed to 
create a file. Cause: [ERR 0629] A redirect instr

uction failed to create a file.
 [xslt] Failed to process 
C:\Cygwin\svn\incubator\trunk\content\podlings.xml


BUILD FAILED
C:\Cygwin\svn\incubator\trunk\build.xml:192: Fatal error during 
transformation


I see Shane got this a long time ago, but don't see a solution.

http://mail-archives.apache.org/mod_mbox/incubator-general/201204.mbox/%3c4f832326.7040...@shanecurcuru.org%3E

Any idea why this would occur?

Thanks

Kathey

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

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Liang Chen

+1 (non-binding) 



--
View this message in context: 
http://apache-incubator-general.996316.n3.nabble.com/VOTE-Accept-Mnemonic-into-the-Apache-Incubator-tp48618p48636.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 Mnemonic into the Apache Incubator

2016-02-29 Thread Zheng, Kai

+1 (non-binding)

Regards,
Kai

-Original Message-
From: Patrick Hunt [mailto:ph...@apache.org] 
Sent: Tuesday, March 01, 2016 1:38 AM
To: general@incubator.apache.org
Subject: [VOTE] Accept Mnemonic into the Apache Incubator

Hi folks,

OK the discussion is now completed. Please VOTE to accept Mnemonic into the 
Apache Incubator. I’ll leave the VOTE open for at least the next 72 hours, with 
hopes to close it Thursday the 3rd of March, 2016 at 10am PT.
https://wiki.apache.org/incubator/MnemonicProposal

[ ] +1 Accept Mnemonic as an Apache Incubator podling.
[ ] +0 Abstain.
[ ] -1 Don’t accept Mnemonic as an Apache Incubator podling because..

Of course, I am +1 on this. Please note VOTEs from Incubator PMC members are 
binding but all are welcome to VOTE!

Regards,

Patrick

= Mnemonic Proposal =
=== Abstract ===
Mnemonic is a Java based non-volatile memory library for in-place structured 
data processing and computing. It is a solution for generic object and block 
persistence on heterogeneous block and byte-addressable devices, such as DRAM, 
persistent memory, NVMe, SSD, and cloud network storage.

=== Proposal ===
Mnemonic is a structured data persistence in-memory in-place library for 
Java-based applications and frameworks. It provides unified interfaces for data 
manipulation on heterogeneous block/byte-addressable devices, such as DRAM, 
persistent memory, NVMe, SSD, and cloud network devices.

The design motivation for this project is to create a non-volatile programming 
paradigm for in-memory data object persistence, in-memory data objects caching, 
and JNI-less IPC.
Mnemonic simplifies the usage of data object caching, persistence, and JNI-less 
IPC for massive object oriented structural datasets.

Mnemonic defines Non-Volatile Java objects that store data fields in persistent 
memory and storage. During the program runtime, only methods and volatile 
fields are instantiated in Java heap, Non-Volatile data fields are directly 
accessed via GET/SET operation to and from persistent memory and storage. 
Mnemonic avoids SerDes and significantly reduces amount of garbage in Java heap.

Major features of Mnemonic:
* Provides an abstract level of viewpoint to utilize heterogeneous 
block/byte-addressable device as a whole (e.g., DRAM, persistent memory, NVMe, 
SSD, HD, cloud network Storage).

* Provides seamless support object oriented design and programming without 
adding burden to transfer object data to different form.

* Avoids the object data serialization/de-serialization for data retrieval, 
caching and storage.

* Reduces the consumption of on-heap memory and in turn to reduce and stabilize 
Java Garbage Collection (GC) pauses for latency sensitive applications.

* Overcomes current limitations of Java GC to manage much larger memory 
resources for massive dataset processing and computing.

* Supports the migration data usage model from traditional NVMe/SSD/HD to 
non-volatile memory with ease.

* Uses lazy loading mechanism to avoid unnecessary memory consumption if some 
data does not need to use for computing immediately.

* Bypasses JNI call for the interaction between Java runtime application and 
its native code.

* Provides an allocation aware auto-reclaim mechanism to prevent external 
memory resource leaking.

=== Background ===
Big Data and Cloud applications increasingly require both high throughput and 
low latency processing. Java-based applications targeting the Big Data and 
Cloud space should be tuned for better throughput, lower latency, and more 
predictable response time.
Typically, there are some issues that impact BigData applications'
performance and scalability:

1) The Complexity of Data Transformation/Organization: In most cases, during 
data processing, applications use their own complicated data caching mechanism 
for SerDes data objects, spilling to different storage and eviction large 
amount of data. Some data objects contains complex values and structure that 
will make it much more difficulty for data organization. To load and then 
parse/decode its datasets from storage consumes high system resource and 
computation power.

2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes Frequent 
Long GC Pauses: Big Data computing/syntax generates large amount of temporary 
objects during processing, e.g. lambda, SerDes, copying and etc. This will 
trigger frequent long Java GC pause to scan references, to update references 
lists, and to copy live objects from one memory location to another blindly.

3) The Unpredictable GC Pause: For latency sensitive applications, such as 
database, search engine, web query, real-time/streaming computing, require 
latency/request-response under control. But current Java GC does not provide 
predictable GC activities with large on-heap memory management.

4) High JNI Invocation Cost: JNI calls are expensive, but high performance 
applications usually try to leverage native code to

Re: Copyright sign offs

2016-02-29 Thread John D. Ament

Dennis,

For some reason, Oliver Rau added you in this commit
https://svn.apache.org/viewvc/incubator/public/trunk/content/projects/odftoolkit.xml?r1=1296007=1531246
If you don't belong, you should be able to remove yourself.

John

On Mon, Feb 29, 2016 at 6:30 PM Dennis E. Hamilton 
wrote:

> Henri,
>
> I did a quick look at the odftoolkit repository and the podling page.
>
> The odftoolkit project was originally under ALv2.  The code still carries
> Copyright notices on the individual files and the ALv2 license statement
> has not been updated/replaced by the current one mentioning contribution to
> the ASF, etc.
>
> In passing, I notice a peculiarity of the incubator page,
> .  I'm certain I
> was never on the PPMC and I don't think I was a committer either, unless it
> is transitive via incubator (a change since 2012?).  My impression was that
> the PPMC was rather small.  I have no idea what its current membership is.
>
> There has been recent maintenance on the source code, some working against
> JIRA issues, as reported in the February 2016 Incubator Report.
>
>  - Dennis
>
>
> > -Original Message-
> > From: Henri Yandell [mailto:bay...@apache.org]
> > Sent: Friday, February 26, 2016 17:28
> > To: general@incubator.apache.org
> > Subject: Copyright sign offs
> >
> > Haven't done this in a while :)
> >
> > Thought I'd share that the following podlings have not yet signed off on
> > their Copyright sections in their status reports. I mention this because
> > I
> > believe it's one of the first elements that should be signed off on the
> > status report and it's a worry if projects have not done so:
> >
> >   cmda
> >   datafu
> >   horn
> >   johnzon
> >   odftoolkit
> [ ... ]
> >
> > I'd be interested to hear about any reasons why the above aren't able to
> > sign that element of their status file off.
> [ ... ]
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

RE: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread ozawa

+1(non-binding)

Regards,
-Tsuyoshi

-Original Message-
From: Patrick Hunt [mailto:ph...@apache.org] 
Sent: Tuesday, March 01, 2016 2:38 AM
To: general@incubator.apache.org
Subject: [VOTE] Accept Mnemonic into the Apache Incubator

Hi folks,

OK the discussion is now completed. Please VOTE to accept Mnemonic into the 
Apache Incubator. I’ll leave the VOTE open for at least the next 72 hours, with 
hopes to close it Thursday the 3rd of March, 2016 at 10am PT.
https://wiki.apache.org/incubator/MnemonicProposal

[ ] +1 Accept Mnemonic as an Apache Incubator podling.
[ ] +0 Abstain.
[ ] -1 Don’t accept Mnemonic as an Apache Incubator podling because..

Of course, I am +1 on this. Please note VOTEs from Incubator PMC members are 
binding but all are welcome to VOTE!

Regards,

Patrick

= Mnemonic Proposal =
=== Abstract ===
Mnemonic is a Java based non-volatile memory library for in-place structured 
data processing and computing. It is a solution for generic object and block 
persistence on heterogeneous block and byte-addressable devices, such as DRAM, 
persistent memory, NVMe, SSD, and cloud network storage.

=== Proposal ===
Mnemonic is a structured data persistence in-memory in-place library for 
Java-based applications and frameworks. It provides unified interfaces for data 
manipulation on heterogeneous block/byte-addressable devices, such as DRAM, 
persistent memory, NVMe, SSD, and cloud network devices.

The design motivation for this project is to create a non-volatile programming 
paradigm for in-memory data object persistence, in-memory data objects caching, 
and JNI-less IPC.
Mnemonic simplifies the usage of data object caching, persistence, and JNI-less 
IPC for massive object oriented structural datasets.

Mnemonic defines Non-Volatile Java objects that store data fields in persistent 
memory and storage. During the program runtime, only methods and volatile 
fields are instantiated in Java heap, Non-Volatile data fields are directly 
accessed via GET/SET operation to and from persistent memory and storage. 
Mnemonic avoids SerDes and significantly reduces amount of garbage in Java heap.

Major features of Mnemonic:
* Provides an abstract level of viewpoint to utilize heterogeneous 
block/byte-addressable device as a whole (e.g., DRAM, persistent memory, NVMe, 
SSD, HD, cloud network Storage).

* Provides seamless support object oriented design and programming without 
adding burden to transfer object data to different form.

* Avoids the object data serialization/de-serialization for data retrieval, 
caching and storage.

* Reduces the consumption of on-heap memory and in turn to reduce and stabilize 
Java Garbage Collection (GC) pauses for latency sensitive applications.

* Overcomes current limitations of Java GC to manage much larger memory 
resources for massive dataset processing and computing.

* Supports the migration data usage model from traditional NVMe/SSD/HD to 
non-volatile memory with ease.

* Uses lazy loading mechanism to avoid unnecessary memory consumption if some 
data does not need to use for computing immediately.

* Bypasses JNI call for the interaction between Java runtime application and 
its native code.

* Provides an allocation aware auto-reclaim mechanism to prevent external 
memory resource leaking.

=== Background ===
Big Data and Cloud applications increasingly require both high throughput and 
low latency processing. Java-based applications targeting the Big Data and 
Cloud space should be tuned for better throughput, lower latency, and more 
predictable response time.
Typically, there are some issues that impact BigData applications'
performance and scalability:

1) The Complexity of Data Transformation/Organization: In most cases, during 
data processing, applications use their own complicated data caching mechanism 
for SerDes data objects, spilling to different storage and eviction large 
amount of data. Some data objects contains complex values and structure that 
will make it much more difficulty for data organization. To load and then 
parse/decode its datasets from storage consumes high system resource and 
computation power.

2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes Frequent 
Long GC Pauses: Big Data computing/syntax generates large amount of temporary 
objects during processing, e.g. lambda, SerDes, copying and etc. This will 
trigger frequent long Java GC pause to scan references, to update references 
lists, and to copy live objects from one memory location to another blindly.

3) The Unpredictable GC Pause: For latency sensitive applications, such as 
database, search engine, web query, real-time/streaming computing, require 
latency/request-response under control. But current Java GC does not provide 
predictable GC activities with large on-heap memory management.

4) High JNI Invocation Cost: JNI calls are expensive, but high performance 
applications usually try to leverage native code to

[VOTE] Release Apache Ranger 0.5.2 (incubating)

2016-02-29 Thread Madhan Neethiraj

Incubator PMC,

The Apache Ranger community has voted on and approved the proposal to release 
Apache Ranger 0.5.2 (incubating). The voting result is available at 
http://mail-archives.apache.org/mod_mbox/incubator-ranger-dev/201602.mbox/%3c62fd4d6f-2a7e-4b7a-b9ce-347f868c2...@apache.org%3e.
 

Prior releases of Apache Ranger (incubating) are:
  - Apache Ranger 0.5.1 Jan 2016
  - Apache Ranger 0.5.0 Jul 2015
  - Apache Ranger 0.4.0 Nov 2014


Artifacts for this release are given below:
  - Git tag for the release: 
https://git-wip-us.apache.org/repos/asf?p=incubator-ranger.git;a=shortlog;h=refs/tags/ranger-0.5.2-rc1
  - Sources for the release: 
http://people.apache.org/~madhan/ranger/ranger-0.5.2-rc1/apache-ranger-incubating-0.5.2.tar.gz
  - Source release verification:
- PGP Signature:   
http://people.apache.org/~madhan/ranger/ranger-0.5.2-rc1/apache-ranger-incubating-0.5.2.tar.gz.asc
- MD5/SHA  Hash:  
http://people.apache.org/~madhan/ranger/ranger-0.5.2-rc1/apache-ranger-incubating-0.5.2.tar.gz.mds
- Keys to verify the signature of the release artifact are available at:  
https://people.apache.org/keys/group/incubator.asc



Please review and vote.


The vote will be open for at least 72 hours or until necessary number of votes 
is reached.
  [  ] +1  approve
  [  ] +0  no opinion
  [  ] -1  disapprove (and reason why)

Here is my +1 (non binding).

There is already one binding +1 vote from Alan Gates.

Thanks
Madhan





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

RE: Copyright sign offs

2016-02-29 Thread Dennis E. Hamilton

Henri,

I did a quick look at the odftoolkit repository and the podling page.

The odftoolkit project was originally under ALv2.  The code still carries 
Copyright notices on the individual files and the ALv2 license statement has 
not been updated/replaced by the current one mentioning contribution to the 
ASF, etc.

In passing, I notice a peculiarity of the incubator page, 
.  I'm certain I was 
never on the PPMC and I don't think I was a committer either, unless it is 
transitive via incubator (a change since 2012?).  My impression was that the 
PPMC was rather small.  I have no idea what its current membership is.

There has been recent maintenance on the source code, some working against JIRA 
issues, as reported in the February 2016 Incubator Report.

 - Dennis

 
> -Original Message-
> From: Henri Yandell [mailto:bay...@apache.org]
> Sent: Friday, February 26, 2016 17:28
> To: general@incubator.apache.org
> Subject: Copyright sign offs
> 
> Haven't done this in a while :)
> 
> Thought I'd share that the following podlings have not yet signed off on
> their Copyright sections in their status reports. I mention this because
> I
> believe it's one of the first elements that should be signed off on the
> status report and it's a worry if projects have not done so:
> 
>   cmda
>   datafu
>   horn
>   johnzon
>   odftoolkit
[ ... ]
> 
> I'd be interested to hear about any reasons why the above aren't able to
> sign that element of their status file off.
[ ... ]


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

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Chris Nauroth

+1 (binding)

--Chris Nauroth




On 2/29/16, 9:37 AM, "Patrick Hunt"  wrote:

>Hi folks,
>
>OK the discussion is now completed. Please VOTE to accept Mnemonic
>into the Apache Incubator. I¹ll leave the VOTE open for at least
>the next 72 hours, with hopes to close it Thursday the 3rd of
>March, 2016 at 10am PT.
>https://wiki.apache.org/incubator/MnemonicProposal
>
>[ ] +1 Accept Mnemonic as an Apache Incubator podling.
>[ ] +0 Abstain.
>[ ] -1 Don¹t accept Mnemonic as an Apache Incubator podling because..
>
>Of course, I am +1 on this. Please note VOTEs from Incubator PMC
>members are binding but all are welcome to VOTE!
>
>Regards,
>
>Patrick
>
>
>= Mnemonic Proposal =
>=== Abstract ===
>Mnemonic is a Java based non-volatile memory library for in-place
>structured data processing and computing. It is a solution for generic
>object and block persistence on heterogeneous block and
>byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD,
>and cloud network storage.
>
>=== Proposal ===
>Mnemonic is a structured data persistence in-memory in-place library
>for Java-based applications and frameworks. It provides unified
>interfaces for data manipulation on heterogeneous
>block/byte-addressable devices, such as DRAM, persistent memory, NVMe,
>SSD, and cloud network devices.
>
>The design motivation for this project is to create a non-volatile
>programming paradigm for in-memory data object persistence, in-memory
>data objects caching, and JNI-less IPC.
>Mnemonic simplifies the usage of data object caching, persistence, and
>JNI-less IPC for massive object oriented structural datasets.
>
>Mnemonic defines Non-Volatile Java objects that store data fields in
>persistent memory and storage. During the program runtime, only
>methods and volatile fields are instantiated in Java heap,
>Non-Volatile data fields are directly accessed via GET/SET operation
>to and from persistent memory and storage. Mnemonic avoids SerDes and
>significantly reduces amount of garbage in Java heap.
>
>Major features of Mnemonic:
>* Provides an abstract level of viewpoint to utilize heterogeneous
>block/byte-addressable device as a whole (e.g., DRAM, persistent
>memory, NVMe, SSD, HD, cloud network Storage).
>
>* Provides seamless support object oriented design and programming
>without adding burden to transfer object data to different form.
>
>* Avoids the object data serialization/de-serialization for data
>retrieval, caching and storage.
>
>* Reduces the consumption of on-heap memory and in turn to reduce and
>stabilize Java Garbage Collection (GC) pauses for latency sensitive
>applications.
>
>* Overcomes current limitations of Java GC to manage much larger
>memory resources for massive dataset processing and computing.
>
>* Supports the migration data usage model from traditional NVMe/SSD/HD
>to non-volatile memory with ease.
>
>* Uses lazy loading mechanism to avoid unnecessary memory consumption
>if some data does not need to use for computing immediately.
>
>* Bypasses JNI call for the interaction between Java runtime
>application and its native code.
>
>* Provides an allocation aware auto-reclaim mechanism to prevent
>external memory resource leaking.
>
>
>=== Background ===
>Big Data and Cloud applications increasingly require both high
>throughput and low latency processing. Java-based applications
>targeting the Big Data and Cloud space should be tuned for better
>throughput, lower latency, and more predictable response time.
>Typically, there are some issues that impact BigData applications'
>performance and scalability:
>
>1) The Complexity of Data Transformation/Organization: In most cases,
>during data processing, applications use their own complicated data
>caching mechanism for SerDes data objects, spilling to different
>storage and eviction large amount of data. Some data objects contains
>complex values and structure that will make it much more difficulty
>for data organization. To load and then parse/decode its datasets from
>storage consumes high system resource and computation power.
>
>2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes
>Frequent Long GC Pauses: Big Data computing/syntax generates large
>amount of temporary objects during processing, e.g. lambda, SerDes,
>copying and etc. This will trigger frequent long Java GC pause to scan
>references, to update references lists, and to copy live objects from
>one memory location to another blindly.
>
>3) The Unpredictable GC Pause: For latency sensitive applications,
>such as database, search engine, web query, real-time/streaming
>computing, require latency/request-response under control. But current
>Java GC does not provide predictable GC activities with large on-heap
>memory management.
>
>4) High JNI Invocation Cost: JNI calls are expensive, but high
>performance applications usually try to leverage native code to
>improve performance, however, JNI calls need to convert Java objects
>into

Re: [IP CLEARANCE] Apache Brooklyn - CLI

2016-02-29 Thread Justin Mclean

Hi,

> Apache Brooklyn is receiving a code for a new CLI tool.
> See http://incubator.apache.org/ip-clearance/brooklyn-cli.html 
> 
I notice the code contains MIT and BSD licensed code and crypto code. [1] Was 
this intended?

Thanks,
Justin

1. ./br/Godeps/_workspace/src/golang.org/x/crypto

[IP CLEARANCE] Apache Brooklyn - CLI

2016-02-29 Thread Richard Downer

Apache Brooklyn is receiving a code for a new CLI tool.

See http://incubator.apache.org/ip-clearance/brooklyn-cli.html

Please vote to approve this contribution.

This is a lazy consensus majority vote, open for at least 72 hours.

Thanks
Richard

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

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Andrew Purtell

+1 (binding)

> On 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: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Debo Dutta (dedutta)

+1

On 2/29/16, 9:37 AM, "Patrick Hunt"  wrote:

>Hi folks,
>
>OK the discussion is now completed. Please VOTE to accept Mnemonic
>into the Apache Incubator. I¹ll leave the VOTE open for at least
>the next 72 hours, with hopes to close it Thursday the 3rd of
>March, 2016 at 10am PT.
>https://wiki.apache.org/incubator/MnemonicProposal
>
>[ ] +1 Accept Mnemonic as an Apache Incubator podling.
>[ ] +0 Abstain.
>[ ] -1 Don¹t accept Mnemonic as an Apache Incubator podling because..
>
>Of course, I am +1 on this. Please note VOTEs from Incubator PMC
>members are binding but all are welcome to VOTE!
>
>Regards,
>
>Patrick
>
>
>= Mnemonic Proposal =
>=== Abstract ===
>Mnemonic is a Java based non-volatile memory library for in-place
>structured data processing and computing. It is a solution for generic
>object and block persistence on heterogeneous block and
>byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD,
>and cloud network storage.
>
>=== Proposal ===
>Mnemonic is a structured data persistence in-memory in-place library
>for Java-based applications and frameworks. It provides unified
>interfaces for data manipulation on heterogeneous
>block/byte-addressable devices, such as DRAM, persistent memory, NVMe,
>SSD, and cloud network devices.
>
>The design motivation for this project is to create a non-volatile
>programming paradigm for in-memory data object persistence, in-memory
>data objects caching, and JNI-less IPC.
>Mnemonic simplifies the usage of data object caching, persistence, and
>JNI-less IPC for massive object oriented structural datasets.
>
>Mnemonic defines Non-Volatile Java objects that store data fields in
>persistent memory and storage. During the program runtime, only
>methods and volatile fields are instantiated in Java heap,
>Non-Volatile data fields are directly accessed via GET/SET operation
>to and from persistent memory and storage. Mnemonic avoids SerDes and
>significantly reduces amount of garbage in Java heap.
>
>Major features of Mnemonic:
>* Provides an abstract level of viewpoint to utilize heterogeneous
>block/byte-addressable device as a whole (e.g., DRAM, persistent
>memory, NVMe, SSD, HD, cloud network Storage).
>
>* Provides seamless support object oriented design and programming
>without adding burden to transfer object data to different form.
>
>* Avoids the object data serialization/de-serialization for data
>retrieval, caching and storage.
>
>* Reduces the consumption of on-heap memory and in turn to reduce and
>stabilize Java Garbage Collection (GC) pauses for latency sensitive
>applications.
>
>* Overcomes current limitations of Java GC to manage much larger
>memory resources for massive dataset processing and computing.
>
>* Supports the migration data usage model from traditional NVMe/SSD/HD
>to non-volatile memory with ease.
>
>* Uses lazy loading mechanism to avoid unnecessary memory consumption
>if some data does not need to use for computing immediately.
>
>* Bypasses JNI call for the interaction between Java runtime
>application and its native code.
>
>* Provides an allocation aware auto-reclaim mechanism to prevent
>external memory resource leaking.
>
>
>=== Background ===
>Big Data and Cloud applications increasingly require both high
>throughput and low latency processing. Java-based applications
>targeting the Big Data and Cloud space should be tuned for better
>throughput, lower latency, and more predictable response time.
>Typically, there are some issues that impact BigData applications'
>performance and scalability:
>
>1) The Complexity of Data Transformation/Organization: In most cases,
>during data processing, applications use their own complicated data
>caching mechanism for SerDes data objects, spilling to different
>storage and eviction large amount of data. Some data objects contains
>complex values and structure that will make it much more difficulty
>for data organization. To load and then parse/decode its datasets from
>storage consumes high system resource and computation power.
>
>2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes
>Frequent Long GC Pauses: Big Data computing/syntax generates large
>amount of temporary objects during processing, e.g. lambda, SerDes,
>copying and etc. This will trigger frequent long Java GC pause to scan
>references, to update references lists, and to copy live objects from
>one memory location to another blindly.
>
>3) The Unpredictable GC Pause: For latency sensitive applications,
>such as database, search engine, web query, real-time/streaming
>computing, require latency/request-response under control. But current
>Java GC does not provide predictable GC activities with large on-heap
>memory management.
>
>4) High JNI Invocation Cost: JNI calls are expensive, but high
>performance applications usually try to leverage native code to
>improve performance, however, JNI calls need to convert Java objects
>into something that C/C++ can

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Gangumalla, Uma

+1 (non-binding)

Regards,
Uma

On 2/29/16, 9:37 AM, "Patrick Hunt"  wrote:

>Hi folks,
>
>OK the discussion is now completed. Please VOTE to accept Mnemonic
>into the Apache Incubator. I¹ll leave the VOTE open for at least
>the next 72 hours, with hopes to close it Thursday the 3rd of
>March, 2016 at 10am PT.
>https://wiki.apache.org/incubator/MnemonicProposal
>
>[ ] +1 Accept Mnemonic as an Apache Incubator podling.
>[ ] +0 Abstain.
>[ ] -1 Don¹t accept Mnemonic as an Apache Incubator podling because..
>
>Of course, I am +1 on this. Please note VOTEs from Incubator PMC
>members are binding but all are welcome to VOTE!
>
>Regards,
>
>Patrick
>
>
>= Mnemonic Proposal =
>=== Abstract ===
>Mnemonic is a Java based non-volatile memory library for in-place
>structured data processing and computing. It is a solution for generic
>object and block persistence on heterogeneous block and
>byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD,
>and cloud network storage.
>
>=== Proposal ===
>Mnemonic is a structured data persistence in-memory in-place library
>for Java-based applications and frameworks. It provides unified
>interfaces for data manipulation on heterogeneous
>block/byte-addressable devices, such as DRAM, persistent memory, NVMe,
>SSD, and cloud network devices.
>
>The design motivation for this project is to create a non-volatile
>programming paradigm for in-memory data object persistence, in-memory
>data objects caching, and JNI-less IPC.
>Mnemonic simplifies the usage of data object caching, persistence, and
>JNI-less IPC for massive object oriented structural datasets.
>
>Mnemonic defines Non-Volatile Java objects that store data fields in
>persistent memory and storage. During the program runtime, only
>methods and volatile fields are instantiated in Java heap,
>Non-Volatile data fields are directly accessed via GET/SET operation
>to and from persistent memory and storage. Mnemonic avoids SerDes and
>significantly reduces amount of garbage in Java heap.
>
>Major features of Mnemonic:
>* Provides an abstract level of viewpoint to utilize heterogeneous
>block/byte-addressable device as a whole (e.g., DRAM, persistent
>memory, NVMe, SSD, HD, cloud network Storage).
>
>* Provides seamless support object oriented design and programming
>without adding burden to transfer object data to different form.
>
>* Avoids the object data serialization/de-serialization for data
>retrieval, caching and storage.
>
>* Reduces the consumption of on-heap memory and in turn to reduce and
>stabilize Java Garbage Collection (GC) pauses for latency sensitive
>applications.
>
>* Overcomes current limitations of Java GC to manage much larger
>memory resources for massive dataset processing and computing.
>
>* Supports the migration data usage model from traditional NVMe/SSD/HD
>to non-volatile memory with ease.
>
>* Uses lazy loading mechanism to avoid unnecessary memory consumption
>if some data does not need to use for computing immediately.
>
>* Bypasses JNI call for the interaction between Java runtime
>application and its native code.
>
>* Provides an allocation aware auto-reclaim mechanism to prevent
>external memory resource leaking.
>
>
>=== Background ===
>Big Data and Cloud applications increasingly require both high
>throughput and low latency processing. Java-based applications
>targeting the Big Data and Cloud space should be tuned for better
>throughput, lower latency, and more predictable response time.
>Typically, there are some issues that impact BigData applications'
>performance and scalability:
>
>1) The Complexity of Data Transformation/Organization: In most cases,
>during data processing, applications use their own complicated data
>caching mechanism for SerDes data objects, spilling to different
>storage and eviction large amount of data. Some data objects contains
>complex values and structure that will make it much more difficulty
>for data organization. To load and then parse/decode its datasets from
>storage consumes high system resource and computation power.
>
>2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes
>Frequent Long GC Pauses: Big Data computing/syntax generates large
>amount of temporary objects during processing, e.g. lambda, SerDes,
>copying and etc. This will trigger frequent long Java GC pause to scan
>references, to update references lists, and to copy live objects from
>one memory location to another blindly.
>
>3) The Unpredictable GC Pause: For latency sensitive applications,
>such as database, search engine, web query, real-time/streaming
>computing, require latency/request-response under control. But current
>Java GC does not provide predictable GC activities with large on-heap
>memory management.
>
>4) High JNI Invocation Cost: JNI calls are expensive, but high
>performance applications usually try to leverage native code to
>improve performance, however, JNI calls need to convert Java objects
>into

RE: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Vasudevan, Ramkrishna S

+1 (non-binding)

Regards
Ram

-Original Message-
From: James Taylor [mailto:jamestay...@apache.org] 
Sent: Monday, February 29, 2016 11:34 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Accept Mnemonic into the Apache Incubator

+1 (binding)

On Mon, Feb 29, 2016 at 10:03 AM, Phillip Rhodes 
wrote:

> +1
> On Feb 29, 2016 12:57, "Henry Saputra"  wrote:
>
> > +1 (Binding)
> >
> > - Henry
> >
> > 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

[RESULT] [VOTE] Accept Quarks into the Apache Incubator

2016-02-29 Thread Katherine Marsden

This vote passes with the following votes

+1 binding
Katherine Marsden, Luciano Resende, Raymond Feng, Daniel Debrunner,
Flavio Junqueira, Arvind Prabhakar, James Taylor, Julian Hyde, Phillip
Rhodes, Charitha

Note:Dan and I were confirmed as IPMC members this morning, so I
updated our votes to binding.

+1 non-binding
Kathy Saunders, Sandeep Deshmukh, Bhupesh Chawda, Amol Kekre, William
Marshall

0 - none
-1 - none

Final tally is 10 binding +1, 5 non-binding +1, and no other votes.
Thank you everyone for voting.

Congratulations to the Quarks community! I will start the process with
the other mentors, community, and infrastructure to get the project set
up in the incubator.

Best

Kathey

On 2/24/2016 9:01 AM, Katherine Marsden wrote:
The Quarks proposal has been discussed on the incubator list. The
discussion thread is at:
http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3c56c27489.7090...@apache.org%3E

Feedback from the discussion including addition of mentor Justin
Mclean has been incorporated into the proposal below and available on
the wiki at:

https://wiki.apache.org/incubator/QuarksProposal

Please cast your vote to:
[] +1 - accept Quarks as a new incubating project
[] 0 - not sure
[] -1 - do not accept the Quarks project (because: ...)

Thanks,

Kathey Marsden

= Quarks Proposal =
=== Abstract ===
Quarks is a stream processing programming model and lightweight
runtime to execute analytics at devices on the edge or at the gateway.

=== Proposal ===
. Quarks is a programming model and runtime for streaming analytics
at the edge. Applications are developed using a functional flow api
to define operations on data streams that is executed as a graph of
"oplets" in a lightweight embeddable runtime. The SDK provides
capabilities like windowing, aggregation and connectors with an
extensible model for the community to expand its capabilities.

=== Background ===
. Stream processing systems are commonly used to process data from
edge devices and there is a need to push some of the streaming
analytics to the edge to reduce communication costs, react locally
and offload processing from the central systems. Quarks was developed
by IBM as an entirely new project to provide an SDK and lightweight
embeddable runtime for streaming analytics at the edge. Quarks was
created to be an open source project that could provide edge
analytics to a broad community and foster collaboration on common
analytics and connectors across a broad ecosystem of devices.

=== Rationale ===
. With the growth in number of connected devices (Internet of
Things) there is a need to execute analytics at the edge in order to
take local actions based upon sensor information and/or reduce the
volume of data sent to back-end analytic systems to reduce
communication cost.
Quarks rationale is to provide consistent and easy to use
programming models to allow application developers to focus on their
application rather than issues like device connectivity, threading
etc. Quarks' functional data flow programming model is similar to
systems like Apache Flink, Beam (An incubating Apache project), Java
8 Streams & Apache Spark. The API currently has language bindings
for Java8, Java7 and Android. Quarks was developed to address
requirements for analytics at the edge for IoT use cases that were
not addressed by central analytic solutions. We believe that these
capabilities will be useful to many organizations and that the
diverse nature of edge devices and use cases is best addressed by an
open community. Therefore, we would like to contribute Quarks to the
ASF as an open source project and begin developing a community of
developers and users within Apache.

=== Initial Goals ===
. Quarks initial code contribution provides:

* APIs for developing applications that execute analytics using a
per-event (data item) streaming paradigm including support for
windows against a stream for aggregation

* A micro-kernel style runtime for execution.
* Connectors for MQTT, HTTP, JDBC, File, Apache Kafka & IBM Watson
IoT Platform

* Simple analytics aimed at device sensors (using Apache Common Math)
* Development mode including a web-console to view the graph of
running applications
* Testing mechanism for Quarks applications that integrates with
assertion based testing systems like JUnit
* Android specific functionality such as producing a stream that
contains a phone's sensor events (e.g. ambient temperature, pressure)

* JUnit tests
.
. All of the initial code is implemented using Java 8 and when built
produces jars that can execute on Java 8, Java 7 and Android. The goal
is to encourage community contributions in any area of Quarks, to
expand the community (including new committers) and use of Quarks. We
expect contributions will be driven by real-world use of Quarks by
anyone active in the IoT space such as auto

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread James Taylor

+1 (binding)

On Mon, Feb 29, 2016 at 10:03 AM, Phillip Rhodes 
wrote:

> +1
> On Feb 29, 2016 12:57, "Henry Saputra"  wrote:
>
> > +1 (Binding)
> >
> > - Henry
> >
> > 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

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Phillip Rhodes

+1
On Feb 29, 2016 12:57, "Henry Saputra"  wrote:

> +1 (Binding)
>
> - Henry
>
> 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,

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Henry Saputra

+1 (Binding)

- Henry

On Mon, Feb 29, 2016 at 9:37 AM, Patrick Hunt  wrote:

> Hi folks,
>
> OK the discussion is now completed. Please VOTE to accept Mnemonic
> into the Apache Incubator. I’ll leave the VOTE open for at least
> the next 72 hours, with hopes to close it Thursday the 3rd of
> March, 2016 at 10am PT.
> https://wiki.apache.org/incubator/MnemonicProposal
>
> [ ] +1 Accept Mnemonic as an Apache Incubator podling.
> [ ] +0 Abstain.
> [ ] -1 Don’t accept Mnemonic as an Apache Incubator podling because..
>
> Of course, I am +1 on this. Please note VOTEs from Incubator PMC
> members are binding but all are welcome to VOTE!
>
> Regards,
>
> Patrick
>
> 
> = Mnemonic Proposal =
> === Abstract ===
> Mnemonic is a Java based non-volatile memory library for in-place
> structured data processing and computing. It is a solution for generic
> object and block persistence on heterogeneous block and
> byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD,
> and cloud network storage.
>
> === Proposal ===
> Mnemonic is a structured data persistence in-memory in-place library
> for Java-based applications and frameworks. It provides unified
> interfaces for data manipulation on heterogeneous
> block/byte-addressable devices, such as DRAM, persistent memory, NVMe,
> SSD, and cloud network devices.
>
> The design motivation for this project is to create a non-volatile
> programming paradigm for in-memory data object persistence, in-memory
> data objects caching, and JNI-less IPC.
> Mnemonic simplifies the usage of data object caching, persistence, and
> JNI-less IPC for massive object oriented structural datasets.
>
> Mnemonic defines Non-Volatile Java objects that store data fields in
> persistent memory and storage. During the program runtime, only
> methods and volatile fields are instantiated in Java heap,
> Non-Volatile data fields are directly accessed via GET/SET operation
> to and from persistent memory and storage. Mnemonic avoids SerDes and
> significantly reduces amount of garbage in Java heap.
>
> Major features of Mnemonic:
> * Provides an abstract level of viewpoint to utilize heterogeneous
> block/byte-addressable device as a whole (e.g., DRAM, persistent
> memory, NVMe, SSD, HD, cloud network Storage).
>
> * Provides seamless support object oriented design and programming
> without adding burden to transfer object data to different form.
>
> * Avoids the object data serialization/de-serialization for data
> retrieval, caching and storage.
>
> * Reduces the consumption of on-heap memory and in turn to reduce and
> stabilize Java Garbage Collection (GC) pauses for latency sensitive
> applications.
>
> * Overcomes current limitations of Java GC to manage much larger
> memory resources for massive dataset processing and computing.
>
> * Supports the migration data usage model from traditional NVMe/SSD/HD
> to non-volatile memory with ease.
>
> * Uses lazy loading mechanism to avoid unnecessary memory consumption
> if some data does not need to use for computing immediately.
>
> * Bypasses JNI call for the interaction between Java runtime
> application and its native code.
>
> * Provides an allocation aware auto-reclaim mechanism to prevent
> external memory resource leaking.
>
>
> === Background ===
> Big Data and Cloud applications increasingly require both high
> throughput and low latency processing. Java-based applications
> targeting the Big Data and Cloud space should be tuned for better
> throughput, lower latency, and more predictable response time.
> Typically, there are some issues that impact BigData applications'
> performance and scalability:
>
> 1) The Complexity of Data Transformation/Organization: In most cases,
> during data processing, applications use their own complicated data
> caching mechanism for SerDes data objects, spilling to different
> storage and eviction large amount of data. Some data objects contains
> complex values and structure that will make it much more difficulty
> for data organization. To load and then parse/decode its datasets from
> storage consumes high system resource and computation power.
>
> 2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes
> Frequent Long GC Pauses: Big Data computing/syntax generates large
> amount of temporary objects during processing, e.g. lambda, SerDes,
> copying and etc. This will trigger frequent long Java GC pause to scan
> references, to update references lists, and to copy live objects from
> one memory location to another blindly.
>
> 3) The Unpredictable GC Pause: For latency sensitive applications,
> such as database, search engine, web query, real-time/streaming
> computing, require latency/request-response under control. But current
> Java GC does not provide predictable GC activities with large on-heap
> memory management.
>
> 4) High JNI Invocation Cost: JNI calls are expensive, but high
> performance applications usually try to leverage

Re: [VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread 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

[VOTE] Accept Mnemonic into the Apache Incubator

2016-02-29 Thread Patrick Hunt

Hi folks,

OK the discussion is now completed. Please VOTE to accept Mnemonic
into the Apache Incubator. I’ll leave the VOTE open for at least
the next 72 hours, with hopes to close it Thursday the 3rd of
March, 2016 at 10am PT.
https://wiki.apache.org/incubator/MnemonicProposal

[ ] +1 Accept Mnemonic as an Apache Incubator podling.
[ ] +0 Abstain.
[ ] -1 Don’t accept Mnemonic as an Apache Incubator podling because..

Of course, I am +1 on this. Please note VOTEs from Incubator PMC
members are binding but all are welcome to VOTE!

Regards,

Patrick


= Mnemonic Proposal =
=== Abstract ===
Mnemonic is a Java based non-volatile memory library for in-place
structured data processing and computing. It is a solution for generic
object and block persistence on heterogeneous block and
byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD,
and cloud network storage.

=== Proposal ===
Mnemonic is a structured data persistence in-memory in-place library
for Java-based applications and frameworks. It provides unified
interfaces for data manipulation on heterogeneous
block/byte-addressable devices, such as DRAM, persistent memory, NVMe,
SSD, and cloud network devices.

The design motivation for this project is to create a non-volatile
programming paradigm for in-memory data object persistence, in-memory
data objects caching, and JNI-less IPC.
Mnemonic simplifies the usage of data object caching, persistence, and
JNI-less IPC for massive object oriented structural datasets.

Mnemonic defines Non-Volatile Java objects that store data fields in
persistent memory and storage. During the program runtime, only
methods and volatile fields are instantiated in Java heap,
Non-Volatile data fields are directly accessed via GET/SET operation
to and from persistent memory and storage. Mnemonic avoids SerDes and
significantly reduces amount of garbage in Java heap.

Major features of Mnemonic:
* Provides an abstract level of viewpoint to utilize heterogeneous
block/byte-addressable device as a whole (e.g., DRAM, persistent
memory, NVMe, SSD, HD, cloud network Storage).

* Provides seamless support object oriented design and programming
without adding burden to transfer object data to different form.

* Avoids the object data serialization/de-serialization for data
retrieval, caching and storage.

* Reduces the consumption of on-heap memory and in turn to reduce and
stabilize Java Garbage Collection (GC) pauses for latency sensitive
applications.

* Overcomes current limitations of Java GC to manage much larger
memory resources for massive dataset processing and computing.

* Supports the migration data usage model from traditional NVMe/SSD/HD
to non-volatile memory with ease.

* Uses lazy loading mechanism to avoid unnecessary memory consumption
if some data does not need to use for computing immediately.

* Bypasses JNI call for the interaction between Java runtime
application and its native code.

* Provides an allocation aware auto-reclaim mechanism to prevent
external memory resource leaking.


=== Background ===
Big Data and Cloud applications increasingly require both high
throughput and low latency processing. Java-based applications
targeting the Big Data and Cloud space should be tuned for better
throughput, lower latency, and more predictable response time.
Typically, there are some issues that impact BigData applications'
performance and scalability:

1) The Complexity of Data Transformation/Organization: In most cases,
during data processing, applications use their own complicated data
caching mechanism for SerDes data objects, spilling to different
storage and eviction large amount of data. Some data objects contains
complex values and structure that will make it much more difficulty
for data organization. To load and then parse/decode its datasets from
storage consumes high system resource and computation power.

2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes
Frequent Long GC Pauses: Big Data computing/syntax generates large
amount of temporary objects during processing, e.g. lambda, SerDes,
copying and etc. This will trigger frequent long Java GC pause to scan
references, to update references lists, and to copy live objects from
one memory location to another blindly.

3) The Unpredictable GC Pause: For latency sensitive applications,
such as database, search engine, web query, real-time/streaming
computing, require latency/request-response under control. But current
Java GC does not provide predictable GC activities with large on-heap
memory management.

4) High JNI Invocation Cost: JNI calls are expensive, but high
performance applications usually try to leverage native code to
improve performance, however, JNI calls need to convert Java objects
into something that C/C++ can understand. In addition, some
comprehensive native code needs to communicate with Java based
application that will cause frequently JNI call along with stack
marshalling.

Mnemonic

Re: [DISCUSS] Mnemonic incubator proposal

2016-02-29 Thread Henry Saputra

Looks like the discussions had calmed down with no objection so I think we
could proceed with the VOTE thread.

- Henry

On Wed, Feb 24, 2016 at 12:15 PM, Wang, Yanping 
wrote:

> In general, Mnemonic can be integrated into many projects. First, projects
> can use Mnemonic to take data off Java heap so GC can be much reduced, and
> use GET/SET to access data fields so serdes can be eliminated.
> Later we can expand Mnemonic to excise persistent/non-volatile programming
> on large scaled distributed systems with TB sized fast persistent memory
> devices.
>
> Regarding solving Hadoop Namenode pressure of large scale of cluster
> scenarios. This issue is due to HDFS.
> Last year we found the use of FileInputStream in HDFS causes unpredicted
> long Garbage Collection pauses due to the overhead of finalizers and
> significantly impacted HDFS performance and its scalability. We recorded
> the issue in https://issues.apache.org/jira/browse/HDFS-8562
>
> Uma explained what we can do for using Mnemonic to improve HDFS
> performance and scalability. One big advantage is Mnemonic does not need to
> hold File System cache for random access, which will benefit large scale of
> clusters.
>
> Thanks
> yanping
>
>
>
> -Original Message-
> From: Gangumalla, Uma [mailto:uma.ganguma...@intel.com]
> Sent: Tuesday, February 23, 2016 8:06 PM
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Mnemonic incubator proposal
>
> Hi Liang,
>
> Thank you for your interest. Sure we would consider you adding in
> interested contributors list.
>
> >Mnemonic is trying to solve performance issues associated
> with serialization/deserialization of java object when dealing with JVM &
> disk directly as well as GC pressure caused by caching ?
>
> Yes.
>
> >whether Mnemonic could solve Hadoop Namenode pressure of large
> scale of cluster scenaros, or not?
> Yeah, we are thinking on some aspects considering memory and GC overheads
> in Namenode too.
> Example couple of JIRAs already there in HDFS to move some of data
> structure to off heap. So, we had plans to get the standard data structures
> from this library and can make use of them push.
> Also we could make advantage if persistence here.
>
>
> @Yanping/Gary, may be you could add more points if you have?
>
> [Gary] Thanks Uma, in addition, you can plug-in your special allocators
> that could be optimized for namenode usage patterns, by this way, the
> performance could be better and more predictable. Thanks.
>
> Regards,
> Uma
>
> On 2/23/16, 6:48 PM, "Liang Chen"  wrote:
>
> >Interesting, would love to become the contributor
> >
> >My understanding: Mnemonic is trying to solve performance issues
> >associated with serialization/deserialization of java object when
> >dealing with JVM & disk directly as well as GC pressure caused by
> >caching ?
> >
> >one question: whether Mnemonic could solve Hadoop Namenode pressure of
> >large scale of cluster scenaros, or not?
> >
> >
> >
> >--
> >View this message in context:
> >http://apache-incubator-general.996316.n3.nabble.com/DISCUSS-Mnemonic-i
> >ncu
> >bator-proposal-tp48502p48533.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
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release of Apache MRQL 0.9.6 incubating (RC1)

2016-02-29 Thread Ian Dunlop

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

+1 (non binding)
Code in zip & tar.gz builds ok on Windows 7, Java 8, Maven 3.3.3
SHA1 checksum verified for all artifacts.
Licence and notice present and look ok.
GPG key matches for all artifacts (although owner not in my web of
trust so can't verify it).

gpg: Signature made 02/22/16 20:07:39 GMT Standard Time using RSA key
ID 798764F1
gpg: Good signature from "Leonidas Fegaras (for release signing)
" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:  There is no indication that the signature belongs to the
owner.
Primary key fingerprint: F04A 300F 731F 3F10 4A68  24B2 B773 7C07 7987
64F1

Cheers,

Ian


On 28/02/2016 23:11, Leonidas Fegaras wrote:
> Hello, This is a call for a vote on Apache MRQL 0.9.6 incubating. 
> Apache MRQL is a query processing and optimization system for 
> large-scale, distributed data analysis, built on top of Apache
> Hadoop, Hama, Spark, and Flink. This is our fourth release during
> Apache Incubation. A vote was held on the MRQL developer mailing
> list and it passed with four +1 PPMC votes, no -1 votes, and no 0
> votes (see the vote thread [1] and result thread [2]). Two of these
> votes (from Alan D. Cabrera and Edward J. Yoon) carry over as
> binding IPMC votes. We are now requesting that the IPMC members
> review and vote on this release. The vote will be open for at least
> 72 hours and passes if a majority of at least three +1 IPMC votes
> are cast.
> 
> [ ] +1 Release this package as Apache MRQL 0.9.6-incubating [ ]  0
> I don't feel strongly about it, but I'm okay with the release [ ]
> -1 Do not release this package because ...
> 
> The release tarballs, including signatures, digests, etc can be
> found at: 
> https://dist.apache.org/repos/dist/dev/incubator/mrql/0.9.6-incubating
- -RC1/
>
> 
The release candidate consists of the following source distribution
> archives: - apache-mrql-0.9.6-incubating-src.[tar.gz|zip] SHA1 of
> TGZ: C703 9516 1B19 BCAF 4E7E  B460 0E8C 0468 64FE 3995 SHA1 of
> ZIP: 9416 E031 37AE D784 E165  FB5A D0B4 02E0 09AE 3030 You can
> compile the sources using 'mvn clean install'. In addition, the
> following supplementary binary distributions are provided for user
> convenience at the same location: -
> apache-mrql-0.9.6-incubating-bin.[tar.gz|zip] SHA1 of TGZ: D4FC
> 63D1 A4F0 B701 B265  790D 35B9 0701 64C2 47DB SHA1 of ZIP: 733E
> 9033 6085 3ED1 F5A0  270E A160 1230 EB2A 7086
> 
> A staged Maven repository is available for review at: 
> https://repository.apache.org/content/repositories/orgapachemrql-1004
>
>  The release candidate has been signed through the key 798764F1
> in: http://www.apache.org/dist/incubator/mrql/KEYS
> 
> The release candidate is based on the sources tagged with 
> MRQL-0.9.6-incubating-RC1 in: 
> https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=commit;
h=ad4d7c183cb6e8a4b81f89a9cd9a3561a151d18d
>
> 
> 
> List of fixed issues: 
> https://git-wip-us.apache.org/repos/asf?p=incubator-mrql.git;a=blob_pl
ain;f=RELEASE_NOTES;hb=ad4d7c183cb6e8a4b81f89a9cd9a3561a151d18d
>
> 
> 
> To learn more about Apache MRQL, please visit: 
> http://wiki.apache.org/mrql/ Thanks, Leonidas Fegaras
> 
> [1] http://markmail.org/message/w4shq2ndxvrmmnkd [2]
> http://markmail.org/message/ysoji5v74bbsfjdn
> 
> 
> -
>
> 
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

- -- 
Ian Dunlop, eScience Lab
School of Computer Science
The University of Manchester
http://orcid.org/-0001-7066-3350
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJW1FqxAAoJEPK45GBX+Cy5XqIH/Rg13LzUIPSGo2mFi6xV1l+v
qqS2cOIjmTwFM7XQG533SssI56/pe4wExxIfo38/jLXf6KokHwErq/cQPfXXTxUt
RkE/XpD2VxChPqsi80KeKzwraViYUFT32lwneSTI6KBKFdw+X5VphUo48JzKsdGJ
1zVcqJ7tLZ30nseJwopyG0Qeju62xjq5a3xeqGV82AcC7KjaVL2iO4A1eJ3em1F3
PVEsfHsDvJjabiDYGqWbg4e1j7nXcMboLvN05eJsFsUFHeSuNVq95mHgj4s4ORcy
Egs0pEgONspLoSJWYWwd9k+W/mR/nIOJ3ncQTM3ZjkMkkcecUrivRX4kHIrEcmg=
=A5Re
-END PGP SIGNATURE-

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

Re: [MARKETING] New IPMC members Kathey Marsden and Daniel Debrunner

2016-02-29 Thread Marvin Humphrey

On Mon, Feb 29, 2016 at 5:28 AM, Dor Ben Dov  wrote:

> How can one be in the Apache Incubator PMC ?

There are two ways.

The Incubator is an Apache project itself, and like any Apache
project, invites people to join the PMC who have shown merit through
significant contributions to the community.

In addition, any of the 600 or so the "Members" of the ASF, who are
effectively the ASF's shareholders and oversee the Foundation itself,
may join the IPMC at any time by request.

Here's an article describing the ASF's structure:

  https://www.apache.org/foundation/how-it-works.html

Marvin Humphrey

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

Re: Incubator wiki access

2016-02-29 Thread Marvin Humphrey

On Sun, Feb 28, 2016 at 8:16 PM, Mina Lee  wrote:
> Hi, I'd like to get permission to edit wiki.
> My user name is minalee.

Done, enjoy!

Marvin Humphrey

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

RE: [MARKETING] New IPMC members Kathey Marsden and Daniel Debrunner

2016-02-29 Thread Dor Ben Dov

Marvin,

How can one be in the Apache Incubator PMC ? 

Dor

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: יום ב 29 פברואר 2016 15:16
To: general@incubator.apache.org
Subject: [MARKETING] New IPMC members Kathey Marsden and Daniel Debrunner

Greetings,

Two Apache Members have signed up as new members of the Incubator PMC!

Both Kathey Marsden and Daniel John Debrunner are veteran contributors to the 
Apache DB project and Apache Derby.  Kathey is also a member of the Community 
Development PMC.

Welcome!

Marvin Humphrey

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

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,
you may review at http://www.amdocs.com/email_disclaimer.asp

New IPMC members Kathey Marsden and Daniel Debrunner

2016-02-29 Thread Marvin Humphrey

Greetings,

Two Apache Members have signed up as new members of the Incubator PMC!

Both Kathey Marsden and Daniel John Debrunner are veteran contributors
to the Apache DB project and Apache Derby.  Kathey is also a member of
the Community Development PMC.

Welcome!

Marvin Humphrey

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

Re: New mentors for Taverna?

2016-02-29 Thread John D. Ament

Getting Dan into the IPMC is an easy task for him since he's a member.
Unfortunately, the process for adding new mentors to a project is sorely
undefined, but I don't see an issue with the process you described below.

John

On Mon, Feb 29, 2016 at 6:45 AM Stian Soiland-Reyes 
wrote:

> Thank you for your interest, Dan!
>
> Your long experience with Derby and ASF, not to mention the very
> relevant Quarks incubator proposal. would be very welcome by the
> Taverna incubator!
>
> I believe that as an ASF Member you just need to self-nominate to
> become a member of the Incubator PMC, and thus can become a mentor.
> The IPMC folks can help you with the karma granting so you can join
> the incubator SVN group - after which you can add yourself to
>
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/taverna.xml
>
> IPMC folks - is this roughly right?
>
>
>
>
> On 24 February 2016 at 16:56, ddebrunner  wrote:
> > I might be able to be a mentor, let me check and confirm tomorrow if you
> still need mentors by then.
> >
> > Dan.
> >
> >
> > Sent from my T-Mobile 4G LTE Device
> >
> >  Original message From: Ian Dunlop <
> ian.dun...@manchester.ac.uk> Date:2016/02/23  07:59
> (GMT-08:00) To: general@incubator.apache.org Cc:
> Subject: Re: New mentors for Taverna? 
> > Hello,
> >
> > It's an exciting phase for Apache Taverna. We are pushing out a new
> > release and it is a great time for new mentors to get involved. We are a
> > very friendly community. With the new Apache Beam proposal getting
> > started and the Apache Taverna integration points with the Common
> > Workflow Language initiative it's a great time to move into the workflow
> > space.
> >
> > Cheers,
> >
> > Ian
> >
> > On 15/02/2016 08:13, Stian Soiland-Reyes wrote:
> >> No, we are still hoping for a new mentor..
> >> On 14 Feb 2016 17:13, "John D. Ament"  wrote:
> >>
> >>> Just wondering, has anyone stepped up to help Taverna?
> >>>
> >>> John
> >>>
> >>> On Sat, Feb 6, 2016 at 6:56 AM Andy Seaborne  wrote:
> >>>
>  Hi all,
> 
>  I'm one of the "semi-active mentors" of Taverna. In my case, I have a
>  new $job, which is related to some Apache communities but not Taverna.
>  A new job is a busy time so I'm really not able to properly support
> the
>  podling at the moment.  I wish I could but I also have to be
> realistic.
> 
>  Taverna is (I believe) in good shape. Having done an incubator release
>  of part of the codebase, they understand and take the IP issues
>  seriously.  They have added a person to the PPMC.  All-in-all, good
>  progress towards graduation and getting more of the codebase out is
> the
>  next step.
> 
>  So - please could Taverna have some additional mentors?
> 
>   Andy
> 
>  On 01/02/16 14:36, Stian Soiland-Reyes wrote:
> > The majority of the mentors of the Taverna podling have raised
> > concerns that they no longer have sufficient time available to help
> > Taverna in the incubator.
> >
> > In effect we will then have 2 semi-active mentors remaining for
>  continuity.
> >
> > This has become a concern because Taverna is picking up speed and
> > moving towards releases of the main code base (our first release was
> > for a more self-contained library), and this means some effort is
> > needed to review and guide us through those releases.
> >
> > We in the Taverna PPMC have already learnt a lot about the Apache
> Way,
> > we have done our first release, we had 3 very successful GSOC
> > students, and we have voted in our first new PPMC member.
> >
> > However knowing the effort needed to review a "new" code base for a
> > release, we think it would not be fair on the remaining 2 mentors to
> > take the full burden of responsibility.
> >
> >
> > Therefore we would like to ask the Incubator PMC if anyone would be
> > interested in becoming an active mentor of Taverna as we enter this
> > exciting phase?
> >
> >
> >
> > About Taverna:
> >
> > http://taverna.incubator.apache.org/
> >
> > Taverna is a domain-independent suite of tools used to design and
> > execute data-driven workflows, which invoke a mixture of local and
> > remote (REST, WSDL) services. Taverna is used by scientists and
> > researchers in domains like bioinformatics, chemistry, musicology,
> > biodiversity and virtual physiology to combine and process data from
> > multiple sources using a wide variety of analytical tools.
> >
> > Taverna workflows can be designed in a graphical workbench,
> > programmatically through the Taverna Language API, or using an
> > RDF/JSON-based workflow format. They can be executed locally (command
> > line, within workbench or through OSGi-based APIs), or on a

Re: New mentors for Taverna?

2016-02-29 Thread Stian Soiland-Reyes

Thank you for your interest, Dan!

Your long experience with Derby and ASF, not to mention the very
relevant Quarks incubator proposal. would be very welcome by the
Taverna incubator!

I believe that as an ASF Member you just need to self-nominate to
become a member of the Incubator PMC, and thus can become a mentor.
The IPMC folks can help you with the karma granting so you can join
the incubator SVN group - after which you can add yourself to
https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/taverna.xml

IPMC folks - is this roughly right?




On 24 February 2016 at 16:56, ddebrunner  wrote:
> I might be able to be a mentor, let me check and confirm tomorrow if you 
> still need mentors by then.
>
> Dan.
>
>
> Sent from my T-Mobile 4G LTE Device
>
>  Original message From: Ian Dunlop 
>  Date:2016/02/23  07:59  (GMT-08:00) 
> To: general@incubator.apache.org Cc:  
> Subject: Re: New mentors for Taverna? 
> Hello,
>
> It's an exciting phase for Apache Taverna. We are pushing out a new
> release and it is a great time for new mentors to get involved. We are a
> very friendly community. With the new Apache Beam proposal getting
> started and the Apache Taverna integration points with the Common
> Workflow Language initiative it's a great time to move into the workflow
> space.
>
> Cheers,
>
> Ian
>
> On 15/02/2016 08:13, Stian Soiland-Reyes wrote:
>> No, we are still hoping for a new mentor..
>> On 14 Feb 2016 17:13, "John D. Ament"  wrote:
>>
>>> Just wondering, has anyone stepped up to help Taverna?
>>>
>>> John
>>>
>>> On Sat, Feb 6, 2016 at 6:56 AM Andy Seaborne  wrote:
>>>
 Hi all,

 I'm one of the "semi-active mentors" of Taverna. In my case, I have a
 new $job, which is related to some Apache communities but not Taverna.
 A new job is a busy time so I'm really not able to properly support the
 podling at the moment.  I wish I could but I also have to be realistic.

 Taverna is (I believe) in good shape. Having done an incubator release
 of part of the codebase, they understand and take the IP issues
 seriously.  They have added a person to the PPMC.  All-in-all, good
 progress towards graduation and getting more of the codebase out is the
 next step.

 So - please could Taverna have some additional mentors?

  Andy

 On 01/02/16 14:36, Stian Soiland-Reyes wrote:
> The majority of the mentors of the Taverna podling have raised
> concerns that they no longer have sufficient time available to help
> Taverna in the incubator.
>
> In effect we will then have 2 semi-active mentors remaining for
 continuity.
>
> This has become a concern because Taverna is picking up speed and
> moving towards releases of the main code base (our first release was
> for a more self-contained library), and this means some effort is
> needed to review and guide us through those releases.
>
> We in the Taverna PPMC have already learnt a lot about the Apache Way,
> we have done our first release, we had 3 very successful GSOC
> students, and we have voted in our first new PPMC member.
>
> However knowing the effort needed to review a "new" code base for a
> release, we think it would not be fair on the remaining 2 mentors to
> take the full burden of responsibility.
>
>
> Therefore we would like to ask the Incubator PMC if anyone would be
> interested in becoming an active mentor of Taverna as we enter this
> exciting phase?
>
>
>
> About Taverna:
>
> http://taverna.incubator.apache.org/
>
> Taverna is a domain-independent suite of tools used to design and
> execute data-driven workflows, which invoke a mixture of local and
> remote (REST, WSDL) services. Taverna is used by scientists and
> researchers in domains like bioinformatics, chemistry, musicology,
> biodiversity and virtual physiology to combine and process data from
> multiple sources using a wide variety of analytical tools.
>
> Taverna workflows can be designed in a graphical workbench,
> programmatically through the Taverna Language API, or using an
> RDF/JSON-based workflow format. They can be executed locally (command
> line, within workbench or through OSGi-based APIs), or on a Taverna
> server (REST/WSDL), which has been integrated by portals and
> frontends, including an Android mobile app. Taverna results include
> full provenance trace of the execution as we strive to support
> reproducible computational research.
>
> This is an exciting time for us, as we are not just releasing version
> 3 of Taverna, but also working on a Common Workflow Language
> integration (YaML), including support for coordinating Docker-based
> command line tools.
>
>

RE: Copyright sign offs

Re: [VOTE] Apache Apex Malhar Release 3.3.1-incubating (RC1)

Re: Trouble building the incbuator website [ERR 0194]

Re: Copyright sign offs

Re: Trouble building the incbuator website [ERR 0194]

Re: [VOTE] Apache Apex Malhar Release 3.3.1-incubating (RC1)

Re: Trouble building the incbuator website [ERR 0194]

Re: [VOTE] Release of Apache MRQL 0.9.6 incubating (RC1)

Trouble building the incbuator website [ERR 0194]

Re: [VOTE] Accept Mnemonic into the Apache Incubator

RE: [VOTE] Accept Mnemonic into the Apache Incubator

Re: Copyright sign offs

RE: [VOTE] Accept Mnemonic into the Apache Incubator

[VOTE] Release Apache Ranger 0.5.2 (incubating)

RE: Copyright sign offs

Re: [VOTE] Accept Mnemonic into the Apache Incubator

Re: [IP CLEARANCE] Apache Brooklyn - CLI

[IP CLEARANCE] Apache Brooklyn - CLI

Re: [VOTE] Accept Mnemonic into the Apache Incubator

Re: [VOTE] Accept Mnemonic into the Apache Incubator

Re: [VOTE] Accept Mnemonic into the Apache Incubator

RE: [VOTE] Accept Mnemonic into the Apache Incubator

[RESULT] [VOTE] Accept Quarks into the Apache Incubator

Re: [VOTE] Accept Mnemonic into the Apache Incubator

Re: [VOTE] Accept Mnemonic into the Apache Incubator

Re: [VOTE] Accept Mnemonic into the Apache Incubator

Re: [VOTE] Accept Mnemonic into the Apache Incubator

[VOTE] Accept Mnemonic into the Apache Incubator

Re: [DISCUSS] Mnemonic incubator proposal

Re: [VOTE] Release of Apache MRQL 0.9.6 incubating (RC1)

Re: [MARKETING] New IPMC members Kathey Marsden and Daniel Debrunner

Re: Incubator wiki access

RE: [MARKETING] New IPMC members Kathey Marsden and Daniel Debrunner

New IPMC members Kathey Marsden and Daniel Debrunner

Re: New mentors for Taverna?

Re: New mentors for Taverna?

36 matches

Site Navigation

Mail list logo

Footer information