Re: [VOTE] Accept Freemarker into Apache Incubator

2015-06-22 Thread Siegfried Goeschl
+1 (binding)

Siegfried Goeschl

> On 19 Jun 2015, at 09:15, Jacopo Cappellato  wrote:
> 
> Following the discussion in the thread [1], I would like to call a VOTE to 
> accept Freemarker as a new Apache Incubator project.
> 
> The proposal is available on the wiki at [2] and is also attached to this 
> mail.
> 
> The VOTE is open for at least the next 72 hours:
> 
> [ ] +1 accept Freemarker into the Apache Incubator
> [ ] ±0 Abstain
> [ ] -1 because...
> 
> Thank you,
> 
> Jacopo Cappellato
> 
> 1.
> http://mail-archives.apache.org/mod_mbox/incubator-general/201505.mbox/%3cccefe3ed-66c4-4766-a3d2-6d8bda855...@gmail.com%3e
> 
> 2.
> https://wiki.apache.org/incubator/FreemarkerProposal
> 
> ==
> 
> Freemarker Apache Incubator Proposal
> 
> Abstract
> 
> Freemarker is a "template engine", i.e., a generic tool to generate text 
> output based on templates. Freemarker is implemented in Java as a class 
> library for programmers.
> 
> Freemarker is a mature, widely used template engine. We propose to make 
> Freemarker a top level project of the Apache Software Foundation, primarily 
> so that it can build a stronger developer community, which provides more 
> safety, stability and support to the large user base, and also helps evolving 
> the engine and its integration with other projects (many of which are Apache 
> projects).
> 
> Proposal
> 
> Freemarker is a "template engine"; a generic tool that generates text output 
> (HTML web pages, e-mails, configuration files, source code, etc.) based on 
> templates and changing data. It's not an application for end-users in itself, 
> but a Java library, a component that programmers can embed into their 
> products.
> 
> Freemarker was originally created for generating HTML Web pages, particularly 
> in servlet-based applications following the MVC pattern. It’s not bound to 
> servlets or HTML, however.
> 
> The Freemarker Template Language (FTL) is not a full-blown programming 
> language like PHP. It’s a simple, specialized language (although among 
> template languages it’s quite flexible). You meant to prepare the data to 
> display in a real programming language, like issue database queries and do 
> business calculations, and then the template displays that already prepared 
> data.
> 
> Freemarker 1.x was initially released under the LGPL license. Later, by 
> community consensus, we have switched over to a BSD-style license. As of 
> Freemarker 2.2pre1 (2003), the original author, Benjamin Geer, has 
> relinquished the copyright in behalf of Visigoth Software Society, a 
> nonprofit organization started by Jonathan Revusky. With Freemarker 2.3.21 
> (2014) the license has changed to Apache License, Version 2.0, and the owner 
> has changed from Visigoth Software Society to three of the Freemarker 2.x 
> developers, Attila Szegedi, Daniel Dekany, and Jonathan Revusky. Apache 
> License, Version 2.0, is the current license.
> 
> Freemarker is a mature, widely used template engine. While it continues to 
> have a large user base, the active developer community has become rather 
> small at this point, and we think that the "Apache Way" governance model and 
> being part of the ASF (together with other projects that are already using 
> Freemarker) would help to bring new life and energy to the project to better 
> support the maintenance and improvements of the Freemarker codebase. A larger 
> community may also help to improve tooling (such as IDE plugins) and 
> integration with popular frameworks (such as Spring MVC, Struts, etc.), which 
> could foster the adoption of Freemarker. Last but not least, being under the 
> Apache umbrella would put the project into a more trustworthy legal context, 
> which also helps adoption, particularly among bigger corporate users.
> 
> We believe that Freemarker should become a Top Level Project as opposed to a 
> subproject because it has a long history and already a large feature set, 
> codebase and documentation and there is a lot of room for innovation and 
> improvement that would involve more community management; governance and 
> autonomy to make its own direction and manage its own community may be 
> important long term factors for the success of the project.
> 
> Background
> 
> A template engine is a template language with the basic infrastructure around 
> it (configuring, caching, etc.). A template language is a language 
> specialized on generating text based on changing data. Template languages 
> like Freemarker Template Language are by design much simpler than general 
> purpose languages, while providing convenient specialized language devices 
> for tasks that are frequent during text generation.
> 
> Template engines, like Freemarker, play an important role in applications 
> that leverage the MVC (Model View Controller) pattern; for example, several 
> web applications and web application framework implement the MVC pattern in 
> the user interfac

Re: [VOTE] Accept Freemarker into Apache Incubator

2015-06-22 Thread jean-frederic clere

On 06/19/2015 09:15 AM, Jacopo Cappellato wrote:

[ ] +1 accept Freemarker into the Apache Incubator


Cheers

Jean-Frederic

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



[IP-CLEARANCE] CouchDB nano

2015-06-22 Thread Jan Lehnardt
Heya,

on behalf of the CouchDB project, I’d like to request IP Clearance for CouchDB 
nano: 
https://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/couchdb-nano.xml?view=markup

Code: https://dl.dropboxusercontent.com/u/1809262/nano-asf/nano.tar.gz

Origin: https://github.com/dscape/nano

Community vote is positive, ICLAs are filed.

Thank you!
Jan
--


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



[VOTE] Apache Ignite 1.2.0 release (RC2)

2015-06-22 Thread Yakov Zhdanov
Hello!

The Apache Ignite  PPMC has voted to release Apache Ignite 1.2.0-incubating.
The vote was based on the release candidate and thread described below.
We now request the IPMC to vote on this release.

Apache Ignite 1.2.0 release (RC2) has been accepted with 7 votes for (2
binding votes):

   - Branko (binding)
   - Konstantin Boudnik (binding)
   - Gianfranco
   - Sergi
   - Alexey Goncharuk
   - Valentin
   - Semyon

We have uploaded release candidate to
https://dist.apache.org/repos/dist/dev/incubator/ignite/1.2.0-rc2/

Tag name is
ignite-1.2.0-incubating-rc2

1.2.0 changes:
Added client mode to TCP discovery SPI.
Added memory based evictions.
Added integration with Apache Spark.
Added integration with Apache Mesos.
Added serializable cache store factories for built-in stores.
And many more changes which are described in devnotes (link below).

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/ignite-1.2.0-incubating-rc2

RELEASENOTES
https://git-wip-us.apache.org/repos/asf?p=incubator-ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/ignite-1.2.0-incubating-rc2

Please start voting.

+1 - to accept Apache Ignite (incubating) 1.2.0
0 - don't care either way
-1 - DO NOT accept Apache Ignite (incubating) 1.2.0 (explain why)

Here is the PPMC vote thread -
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-1-2-0-release-RC2-td1074.html

This vote will go for 72 hours.

--Yakov


Re: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2

2015-06-22 Thread Dave
CORRECTION: the correct commit ID is in this URL:




On Sun, Jun 21, 2015 at 6:24 PM John D. Ament  wrote:

> +1(agreeing with P. Taylor)
> On Jun 21, 2015 6:16 PM, "P. Taylor Goetz"  wrote:
>
> > Dave,
> >
> > I would think just sending out a correction on this thread with a link to
> > the correct commit should suffice.
> >
> > Bonus points for filing a JIRA to fix the issue and providing a link to
> > that as well. :)
> >
> > -Taylor
> >
> >
> > > On Jun 21, 2015, at 5:40 PM, Dave  wrote:
> > >
> > > Hi John,
> > >
> > > Thanks for your attention to to deal. I think the commit you suggest is
> > the
> > > perfect commit for the release, but the one listed in the email is the
> > same
> > > except for a meaningless change to the CHANGELOG file. We should change
> > > that release script to pick the exact right commit, but I would not
> want
> > to
> > > hold up the release for this.
> > >
> > > Dave
> > >
> > >
> > >
> > > On Sat, Jun 20, 2015 at 11:15 AM John D. Ament 
> > > wrote:
> > >
> > >> Dave,
> > >>
> > >> Looks like the branch referenced has commits on it since the PPMC's
> vote
> > >> started.  Typically we'd point to a commit ID.  Did you perhaps mean
> to
> > >> point to this commit?
> > >>
> > >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git;a=tree;h=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594;hb=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594
> > >>
> > >> John
> > >>
> > >>> On Sat, Jun 20, 2015 at 9:58 AM Dave  wrote:
> > >>>
> > >>> The Apache Usergrid PPMC has voted to release Apache Usergrid 1.0.2
> > >>> (incubating). Now it's time for the Incubator PMC vote.
> > >>>
> > >>> Please vote to release Usergrid 1.0.2.
> > >>>
> > >>> Thanks,
> > >>> Dave
> > >>>
> > >>>
> > >>> -- Forwarded message -
> > >>> From: Dave 
> > >>> Date: Sun, Jun 14, 2015 at 8:11 AM
> > >>> Subject: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2
> > >>> To: d...@usergrid.incubator.apache.org <
> > d...@usergrid.incubator.apache.org
> > >>>
> > >>>
> > >>>
> > >>> All,
> > >>>
> > >>> I propose that we accept the following release candidate as the
> > official
> > >>> Apache Usergrid 1.0.2 release.
> > >>>
> > >>>
> > >>> Usergrid 1.0.2-rc2 includes the following:
> > >>> ---
> > >>> The CHANGELOG for the release is available at:
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git&f=CHANGELOG&hb=1.0.2-rc2
> > >>>
> > >>> The branch used to create the release candidate is:
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git&hb=1.0.2-rc2
> > >>>
> > >>> The current Git commit ID is f0982b347cda3c20a5d1097ab58592874886719f
> > >>>
> > >>> The release candidate is available at:
> > >>
> >
> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz
> > >>>
> > >>> The MD5 checksum of the release candidate can be found at:
> > >>
> >
> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz.md5
> > >>>
> > >>> The signature of the release candidate can be found at:
> > >>
> >
> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz.asc
> > >>>
> > >>> The GPG key used to sign the release are available at:
> > >>> https://dist.apache.org/repos/dist/dev/incubator/usergrid/KEYS
> > >>>
> > >>> Please download, verify, and test.
> > >>>
> > >>> The vote will close on Wed Jun 17 08:10:39 EDT 2015
> > >>>
> > >>> [ ] +1 Release this as Apache Usergrid 1.0.2
> > >>> [ ] +0
> > >>> [ ] -1 Do not release this as Apache Usergrid 1.0.2 because...
> > >>
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>


Re: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2

2015-06-22 Thread Dave
CORRECTION: the correct Git commit ID is specified in this URL:

https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git;a=tree;h=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594;hb=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594

and I filed a JIRA issue to fix the release script so that that it uses the
correct commit ID, here:

  https://issues.apache.org/jira/browse/USERGRID-762

Thanks, John and Taylor.

Everybody else: please continue voting...

Dave


On Mon, Jun 22, 2015 at 10:51 AM Dave  wrote:

> CORRECTION: the correct commit ID is in this URL:
>
>
>
>
> On Sun, Jun 21, 2015 at 6:24 PM John D. Ament 
> wrote:
>
>> +1(agreeing with P. Taylor)
>> On Jun 21, 2015 6:16 PM, "P. Taylor Goetz"  wrote:
>>
>> > Dave,
>> >
>> > I would think just sending out a correction on this thread with a link
>> to
>> > the correct commit should suffice.
>> >
>> > Bonus points for filing a JIRA to fix the issue and providing a link to
>> > that as well. :)
>> >
>> > -Taylor
>> >
>> >
>> > > On Jun 21, 2015, at 5:40 PM, Dave  wrote:
>> > >
>> > > Hi John,
>> > >
>> > > Thanks for your attention to to deal. I think the commit you suggest
>> is
>> > the
>> > > perfect commit for the release, but the one listed in the email is the
>> > same
>> > > except for a meaningless change to the CHANGELOG file. We should
>> change
>> > > that release script to pick the exact right commit, but I would not
>> want
>> > to
>> > > hold up the release for this.
>> > >
>> > > Dave
>> > >
>> > >
>> > >
>> > > On Sat, Jun 20, 2015 at 11:15 AM John D. Ament > >
>> > > wrote:
>> > >
>> > >> Dave,
>> > >>
>> > >> Looks like the branch referenced has commits on it since the PPMC's
>> vote
>> > >> started.  Typically we'd point to a commit ID.  Did you perhaps mean
>> to
>> > >> point to this commit?
>> > >>
>> > >>
>> > >>
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git;a=tree;h=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594;hb=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594
>> > >>
>> > >> John
>> > >>
>> > >>> On Sat, Jun 20, 2015 at 9:58 AM Dave  wrote:
>> > >>>
>> > >>> The Apache Usergrid PPMC has voted to release Apache Usergrid 1.0.2
>> > >>> (incubating). Now it's time for the Incubator PMC vote.
>> > >>>
>> > >>> Please vote to release Usergrid 1.0.2.
>> > >>>
>> > >>> Thanks,
>> > >>> Dave
>> > >>>
>> > >>>
>> > >>> -- Forwarded message -
>> > >>> From: Dave 
>> > >>> Date: Sun, Jun 14, 2015 at 8:11 AM
>> > >>> Subject: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2
>> > >>> To: d...@usergrid.incubator.apache.org <
>> > d...@usergrid.incubator.apache.org
>> > >>>
>> > >>>
>> > >>>
>> > >>> All,
>> > >>>
>> > >>> I propose that we accept the following release candidate as the
>> > official
>> > >>> Apache Usergrid 1.0.2 release.
>> > >>>
>> > >>>
>> > >>> Usergrid 1.0.2-rc2 includes the following:
>> > >>> ---
>> > >>> The CHANGELOG for the release is available at:
>> > >>
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git&f=CHANGELOG&hb=1.0.2-rc2
>> > >>>
>> > >>> The branch used to create the release candidate is:
>> > >>
>> >
>> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git&hb=1.0.2-rc2
>> > >>>
>> > >>> The current Git commit ID is
>> f0982b347cda3c20a5d1097ab58592874886719f
>> > >>>
>> > >>> The release candidate is available at:
>> > >>
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz
>> > >>>
>> > >>> The MD5 checksum of the release candidate can be found at:
>> > >>
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz.md5
>> > >>>
>> > >>> The signature of the release candidate can be found at:
>> > >>
>> >
>> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz.asc
>> > >>>
>> > >>> The GPG key used to sign the release are available at:
>> > >>> https://dist.apache.org/repos/dist/dev/incubator/usergrid/KEYS
>> > >>>
>> > >>> Please download, verify, and test.
>> > >>>
>> > >>> The vote will close on Wed Jun 17 08:10:39 EDT 2015
>> > >>>
>> > >>> [ ] +1 Release this as Apache Usergrid 1.0.2
>> > >>> [ ] +0
>> > >>> [ ] -1 Do not release this as Apache Usergrid 1.0.2 because...
>> > >>
>> >
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>> >
>>
>


Re: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2

2015-06-22 Thread John D. Ament
+1 binding

Release contents look good.

John

On Mon, Jun 22, 2015 at 10:54 AM Dave  wrote:

> CORRECTION: the correct Git commit ID is specified in this URL:
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git;a=tree;h=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594;hb=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594
>
> and I filed a JIRA issue to fix the release script so that that it uses the
> correct commit ID, here:
>
>   https://issues.apache.org/jira/browse/USERGRID-762
>
> Thanks, John and Taylor.
>
> Everybody else: please continue voting...
>
> Dave
>
>
> On Mon, Jun 22, 2015 at 10:51 AM Dave  wrote:
>
> > CORRECTION: the correct commit ID is in this URL:
> >
> >
> >
> >
> > On Sun, Jun 21, 2015 at 6:24 PM John D. Ament 
> > wrote:
> >
> >> +1(agreeing with P. Taylor)
> >> On Jun 21, 2015 6:16 PM, "P. Taylor Goetz"  wrote:
> >>
> >> > Dave,
> >> >
> >> > I would think just sending out a correction on this thread with a link
> >> to
> >> > the correct commit should suffice.
> >> >
> >> > Bonus points for filing a JIRA to fix the issue and providing a link
> to
> >> > that as well. :)
> >> >
> >> > -Taylor
> >> >
> >> >
> >> > > On Jun 21, 2015, at 5:40 PM, Dave  wrote:
> >> > >
> >> > > Hi John,
> >> > >
> >> > > Thanks for your attention to to deal. I think the commit you suggest
> >> is
> >> > the
> >> > > perfect commit for the release, but the one listed in the email is
> the
> >> > same
> >> > > except for a meaningless change to the CHANGELOG file. We should
> >> change
> >> > > that release script to pick the exact right commit, but I would not
> >> want
> >> > to
> >> > > hold up the release for this.
> >> > >
> >> > > Dave
> >> > >
> >> > >
> >> > >
> >> > > On Sat, Jun 20, 2015 at 11:15 AM John D. Ament <
> johndam...@apache.org
> >> >
> >> > > wrote:
> >> > >
> >> > >> Dave,
> >> > >>
> >> > >> Looks like the branch referenced has commits on it since the PPMC's
> >> vote
> >> > >> started.  Typically we'd point to a commit ID.  Did you perhaps
> mean
> >> to
> >> > >> point to this commit?
> >> > >>
> >> > >>
> >> > >>
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git;a=tree;h=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594;hb=2d4589c8b07fe1928c2e3cfe1acbf4cc2f718594
> >> > >>
> >> > >> John
> >> > >>
> >> > >>> On Sat, Jun 20, 2015 at 9:58 AM Dave  wrote:
> >> > >>>
> >> > >>> The Apache Usergrid PPMC has voted to release Apache Usergrid
> 1.0.2
> >> > >>> (incubating). Now it's time for the Incubator PMC vote.
> >> > >>>
> >> > >>> Please vote to release Usergrid 1.0.2.
> >> > >>>
> >> > >>> Thanks,
> >> > >>> Dave
> >> > >>>
> >> > >>>
> >> > >>> -- Forwarded message -
> >> > >>> From: Dave 
> >> > >>> Date: Sun, Jun 14, 2015 at 8:11 AM
> >> > >>> Subject: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2
> >> > >>> To: d...@usergrid.incubator.apache.org <
> >> > d...@usergrid.incubator.apache.org
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> All,
> >> > >>>
> >> > >>> I propose that we accept the following release candidate as the
> >> > official
> >> > >>> Apache Usergrid 1.0.2 release.
> >> > >>>
> >> > >>>
> >> > >>> Usergrid 1.0.2-rc2 includes the following:
> >> > >>> ---
> >> > >>> The CHANGELOG for the release is available at:
> >> > >>
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git&f=CHANGELOG&hb=1.0.2-rc2
> >> > >>>
> >> > >>> The branch used to create the release candidate is:
> >> > >>
> >> >
> >>
> https://git-wip-us.apache.org/repos/asf?p=incubator-usergrid.git&hb=1.0.2-rc2
> >> > >>>
> >> > >>> The current Git commit ID is
> >> f0982b347cda3c20a5d1097ab58592874886719f
> >> > >>>
> >> > >>> The release candidate is available at:
> >> > >>
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz
> >> > >>>
> >> > >>> The MD5 checksum of the release candidate can be found at:
> >> > >>
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz.md5
> >> > >>>
> >> > >>> The signature of the release candidate can be found at:
> >> > >>
> >> >
> >>
> https://dist.apache.org/repos/dist/dev/incubator/usergrid/1.0.2-rc2/apache-usergrid-1.0.2-rc2-incubating.tar.gz.asc
> >> > >>>
> >> > >>> The GPG key used to sign the release are available at:
> >> > >>> https://dist.apache.org/repos/dist/dev/incubator/usergrid/KEYS
> >> > >>>
> >> > >>> Please download, verify, and test.
> >> > >>>
> >> > >>> The vote will close on Wed Jun 17 08:10:39 EDT 2015
> >> > >>>
> >> > >>> [ ] +1 Release this as Apache Usergrid 1.0.2
> >> > >>> [ ] +0
> >> > >>> [ ] -1 Do not release this as Apache Usergrid 1.0.2 because...
> >> > >>
> >> >
> >> > -
> >> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> > For additional commands, e-mail: general-h...@incubator.apache.org
> >> >
> >> >
> >>
> >
>


Re: June report prep

2015-06-22 Thread Marvin Humphrey
On Mon, Jun 15, 2015 at 6:58 PM, Ted Dunning  wrote:
> On Mon, Jun 15, 2015 at 4:48 PM, Marvin Humphrey 
> wrote:
>
>> There are a few more cleanup and followup tasks to take care of in order to
>> prepare for next month:
>>
>> *   Assign podlings who did not report a "monthly" attribute in
>> podlings.xml.
>> *   Remove any expired "monthly" attributes.
>> *   Run clutch.py.
>> *   Assign shepherds.
>> *   Generate the July report template and publish on the wiki.
>>
>> No hurry, so take a couple days to catch your breath.  Will your schedule
>> allow you to get to those by the end of this week?
>
> It should.  After the presentation tomorrow at Spark Summit, I should be
> clear for a few days.

Hi Ted -- can you take care of these items please?

>> Once you close out this month's cycle, we might also have a conversation
>> about how you think the report process could be improved.
>
> Happy to do so.
>
> So far, the support of the team has been absolutely extraordinary.  The
> only suggestion so far is to help a new VP know that the support exists.
> My assumption was that I was jumping into the deep end.  The facts were
> quite different.

Well, I think we can do better yet if we integrate the Incubator's monthly
reporting into whimsy.  My perception is that the total burden is too high.
In the past it was borne solely by the Chair, which was not at all
sustainable.  Now it is spread, but additional tooling can improve matters
more.

However, I'm trying to hold off on that conversation until the current Chair
has actually performed all the tasks involved with the report and so groks the
full scope.  Hint hint. ;)

Marvin Humphrey

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



Re: [PROPOSAL]Pistachio

2015-06-22 Thread Gavin Li
Wiki has been created for the proposal:
https://wiki.apache.org/incubator/PistachioProposal.

The comments here has been addressed and reflected in the wiki.

Thanks,
Gavin Li

On Fri, Jun 19, 2015 at 11:30 AM, Gavin Li  wrote:

> Henry,
>
> Thanks for the suggestion.
>
> We agree that at early stage we'd better shunt the user discussion to dev
> list to help developing the community. I'll update the proposal on the wiki
> once I have write access on wiki.
>
> THanks,
> Gavin Li
>
> On Fri, Jun 19, 2015 at 10:51 AM, Henry Saputra 
> wrote:
>
>> Since it is mostly used in Yahoo do you need pistachio-user list for now?
>>
>> Usually incubator project should focus all communications in dev@ list
>> to avoid distractions of emails.
>>
>>
>> - Henry
>>
>> On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  wrote:
>> > Hi,
>> >
>> > I want to propose project Pistachio to enter Apache Incubator.
>> >
>> > Below please find the proposal.
>> >
>> > Thanks,
>> > Gavin Li
>> >
>> >
>> >
>> > = Pistachio =
>> >
>> > == Abstract ==
>> >
>> > Pistachio is a fault-tolerant low latency distributed storage system
>> which
>> > enables simple embedding the computation to the storage layer to achieve
>> > best data locality. It evolves from Yahoo’s global user profile storage
>> > system.
>> >
>> > == Proposal ==
>> >
>> > Pistachio is a distributed key value store system with fault tolerance
>> and
>> > consistency guarantee. It supports multiple local storage engine
>> including
>> > in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as the
>> user
>> > profile storage for massive scale global ads products in Yahoo storing
>> 10+
>> > billion user profiles. The performance and reliability has been well
>> proven
>> > on production.
>> >
>> > Pistachio can easily embed computation to the storage layer to achieve
>> the
>> > best data locality to improve the computation performance significantly
>> > which is an innovative model comparing with the normal ways where the
>> > storage and compute are independent to each other.
>> >
>> > == Background ==
>> >
>> > Pistachio is originally designed and optimized for Yahoo’s large scale
>> > global open RTB(real-time bidding) use cases where latency is
>> critical(the
>> > whole request needs to be finished within 100ms including network round
>> > trips). It stores 10+ billion user profiles in 8 data centers.
>> >
>> > Then because of the great performance and the flexibility of local
>> storage
>> > choices, we evolved it to do distributed compute. Rich call back
>> interfaces
>> > are added to supports easy compute directly on top of the storage system
>> > local to the data partition. This model is totally different from the
>> > traditional distributed computation model where the storage and compute
>> are
>> > separated and independent. In the new model we found data locality can
>> be
>> > improved significantly and lots of data access round trips can be
>> reduced
>> > in computation, and the performance can be improved significantly.
>> >
>> > It was publicly announced in April 2015 and currently being hosted in
>> > Github.
>> >
>> > == Rationale ==
>> >
>> > As a key value store system Pistachio is unique in terms of low latency
>> > access with fault tolerance and consistency guarantee. The reliability,
>> > scalability, fault tolerance and performance has been well proven in
>> global
>> > large scale revenue supporting production system in Yahoo.
>> >
>> > As a distributed computation system, it’s an innovative model where the
>> > compute layer is introduced on top of the storage layer natively and
>> > naturally to optimize the data locality of computation.
>> >
>> > Operating the project in “apache way” greatly aligns with the long-term
>> > vision of this project and can greatly help the development of the
>> > community.
>> >
>> > == Current Status ==
>> >
>> > Pistachio was open-sourced and announced in April 2015 and currently
>> being
>> > hosted in Github, it was mainly being developed by the team from Yahoo
>> and
>> > already attracted lots of external developers (20+ watches and forks on
>> > github).
>> >
>> > == Meritocracy ==
>> >
>> > We plan to build an environment following the Apache meritocracy
>> > principles. Many companies including Linkedin, GF securities, Microsoft
>> and
>> > open source communities like deeplearning4j have already expressed
>> > interests or accepted the invitations to participate in this project.
>> >
>> > == Community ==
>> >
>> > Since the announcement of Pistachio we received lots of interests. And
>> the
>> > concept of embedding computation to storage also got lots of
>> recognitions.
>> > We also started to work with other communities like deeplearning4j to
>> build
>> > more application use cases with Pistachio. We believe the community will
>> > grow fast.
>> >
>> > == Core Developers ==
>> >
>> > This project is created by Gavin Li. Core developers are currently
>> mainly
>> > in Yahoo.
>> >
>> > == Alignment 

Re: June report prep

2015-06-22 Thread Sam Ruby
On Mon, Jun 22, 2015 at 11:43 AM, Marvin Humphrey
 wrote:
> On Mon, Jun 15, 2015 at 6:58 PM, Ted Dunning  wrote:
>> On Mon, Jun 15, 2015 at 4:48 PM, Marvin Humphrey 
>> wrote:
>>
>>> There are a few more cleanup and followup tasks to take care of in order to
>>> prepare for next month:
>>>
>>> *   Assign podlings who did not report a "monthly" attribute in
>>> podlings.xml.
>>> *   Remove any expired "monthly" attributes.
>>> *   Run clutch.py.
>>> *   Assign shepherds.
>>> *   Generate the July report template and publish on the wiki.
>>>
>>> No hurry, so take a couple days to catch your breath.  Will your schedule
>>> allow you to get to those by the end of this week?
>>
>> It should.  After the presentation tomorrow at Spark Summit, I should be
>> clear for a few days.
>
> Hi Ted -- can you take care of these items please?
>
>>> Once you close out this month's cycle, we might also have a conversation
>>> about how you think the report process could be improved.
>>
>> Happy to do so.
>>
>> So far, the support of the team has been absolutely extraordinary.  The
>> only suggestion so far is to help a new VP know that the support exists.
>> My assumption was that I was jumping into the deep end.  The facts were
>> quite different.
>
> Well, I think we can do better yet if we integrate the Incubator's monthly
> reporting into whimsy.  My perception is that the total burden is too high.
> In the past it was borne solely by the Chair, which was not at all
> sustainable.  Now it is spread, but additional tooling can improve matters
> more.
>
> However, I'm trying to hold off on that conversation until the current Chair
> has actually performed all the tasks involved with the report and so groks the
> full scope.  Hint hint. ;)

One thing that would be helpful is to take good notes during this
process.  Anything you can do via the command line can be done via a
script - this includes SVN and LDAP.  Anything that requires user
input is generally easier when done via a HTML form (buttons,
textareas, checkboxes and the like).  And steps like "remove expired
monthly attributes" can be automated away entirely.

> Marvin Humphrey

- Sam Ruby

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



Re: [PROPOSAL]Pistachio

2015-06-22 Thread Andrew Purtell
> Pistachio can easily embed computation to the storage layer to achieve the
> best data locality to improve the computation performance significantly
> which is an innovative model comparing with the normal ways where the
> storage and compute are independent to each other.

Have you heard of something called Hadoop?


On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  wrote:

> Hi,
>
> I want to propose project Pistachio to enter Apache Incubator.
>
> Below please find the proposal.
>
> Thanks,
> Gavin Li
>
>
>
> = Pistachio =
>
> == Abstract ==
>
> Pistachio is a fault-tolerant low latency distributed storage system which
> enables simple embedding the computation to the storage layer to achieve
> best data locality. It evolves from Yahoo’s global user profile storage
> system.
>
> == Proposal ==
>
> Pistachio is a distributed key value store system with fault tolerance and
> consistency guarantee. It supports multiple local storage engine including
> in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as the user
> profile storage for massive scale global ads products in Yahoo storing 10+
> billion user profiles. The performance and reliability has been well proven
> on production.
>
> Pistachio can easily embed computation to the storage layer to achieve the
> best data locality to improve the computation performance significantly
> which is an innovative model comparing with the normal ways where the
> storage and compute are independent to each other.
>
> == Background ==
>
> Pistachio is originally designed and optimized for Yahoo’s large scale
> global open RTB(real-time bidding) use cases where latency is critical(the
> whole request needs to be finished within 100ms including network round
> trips). It stores 10+ billion user profiles in 8 data centers.
>
> Then because of the great performance and the flexibility of local storage
> choices, we evolved it to do distributed compute. Rich call back interfaces
> are added to supports easy compute directly on top of the storage system
> local to the data partition. This model is totally different from the
> traditional distributed computation model where the storage and compute are
> separated and independent. In the new model we found data locality can be
> improved significantly and lots of data access round trips can be reduced
> in computation, and the performance can be improved significantly.
>
> It was publicly announced in April 2015 and currently being hosted in
> Github.
>
> == Rationale ==
>
> As a key value store system Pistachio is unique in terms of low latency
> access with fault tolerance and consistency guarantee. The reliability,
> scalability, fault tolerance and performance has been well proven in global
> large scale revenue supporting production system in Yahoo.
>
> As a distributed computation system, it’s an innovative model where the
> compute layer is introduced on top of the storage layer natively and
> naturally to optimize the data locality of computation.
>
> Operating the project in “apache way” greatly aligns with the long-term
> vision of this project and can greatly help the development of the
> community.
>
> == Current Status ==
>
> Pistachio was open-sourced and announced in April 2015 and currently being
> hosted in Github, it was mainly being developed by the team from Yahoo and
> already attracted lots of external developers (20+ watches and forks on
> github).
>
> == Meritocracy ==
>
> We plan to build an environment following the Apache meritocracy
> principles. Many companies including Linkedin, GF securities, Microsoft and
> open source communities like deeplearning4j have already expressed
> interests or accepted the invitations to participate in this project.
>
> == Community ==
>
> Since the announcement of Pistachio we received lots of interests. And the
> concept of embedding computation to storage also got lots of recognitions.
> We also started to work with other communities like deeplearning4j to build
> more application use cases with Pistachio. We believe the community will
> grow fast.
>
> == Core Developers ==
>
> This project is created by Gavin Li. Core developers are currently mainly
> in Yahoo.
>
> == Alignment ==
>
> Pistachio depends on many Apache projects and dependencies including Kafka,
> Helix, Zookeeper, Curator, Apache Commons, etc.
>
> == Known Risks ==
>
> === Orphaned Products ===
>
> The risk of Pistachio being orphaned is small because Yahoo heavily
> invested in this system. It’s the internal storage standard for Yahoo’s
> global ads products and still being expanded. Migration cost from this
> project is very high. We are also working with external communities like
> deeplearning4j and other companies to expand the applications.
>
> === Inexperience with Open Source ===
>
> Core developers are experienced open source contributors in many projects
> including Druid, Spark, Storm, etc. Pistachio committers will be guided by
> the mentors with strong Apache open source pro

Re: [PROPOSAL]Pistachio

2015-06-22 Thread John D. Ament
On Mon, Jun 22, 2015 at 10:26 PM Andrew Purtell  wrote:

> > Pistachio can easily embed computation to the storage layer to achieve
> the
> > best data locality to improve the computation performance significantly
> > which is an innovative model comparing with the normal ways where the
> > storage and compute are independent to each other.
>
> Have you heard of something called Hadoop?
>

Regardless of whether he has or not - what's your point? The ASF has
historically not denied the entry of new projects just because their domain
intersects with another project's.


>
>
> On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  wrote:
>
> > Hi,
> >
> > I want to propose project Pistachio to enter Apache Incubator.
> >
> > Below please find the proposal.
> >
> > Thanks,
> > Gavin Li
> >
> >
> >
> > = Pistachio =
> >
> > == Abstract ==
> >
> > Pistachio is a fault-tolerant low latency distributed storage system
> which
> > enables simple embedding the computation to the storage layer to achieve
> > best data locality. It evolves from Yahoo’s global user profile storage
> > system.
> >
> > == Proposal ==
> >
> > Pistachio is a distributed key value store system with fault tolerance
> and
> > consistency guarantee. It supports multiple local storage engine
> including
> > in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as the
> user
> > profile storage for massive scale global ads products in Yahoo storing
> 10+
> > billion user profiles. The performance and reliability has been well
> proven
> > on production.
> >
> > Pistachio can easily embed computation to the storage layer to achieve
> the
> > best data locality to improve the computation performance significantly
> > which is an innovative model comparing with the normal ways where the
> > storage and compute are independent to each other.
> >
> > == Background ==
> >
> > Pistachio is originally designed and optimized for Yahoo’s large scale
> > global open RTB(real-time bidding) use cases where latency is
> critical(the
> > whole request needs to be finished within 100ms including network round
> > trips). It stores 10+ billion user profiles in 8 data centers.
> >
> > Then because of the great performance and the flexibility of local
> storage
> > choices, we evolved it to do distributed compute. Rich call back
> interfaces
> > are added to supports easy compute directly on top of the storage system
> > local to the data partition. This model is totally different from the
> > traditional distributed computation model where the storage and compute
> are
> > separated and independent. In the new model we found data locality can be
> > improved significantly and lots of data access round trips can be reduced
> > in computation, and the performance can be improved significantly.
> >
> > It was publicly announced in April 2015 and currently being hosted in
> > Github.
> >
> > == Rationale ==
> >
> > As a key value store system Pistachio is unique in terms of low latency
> > access with fault tolerance and consistency guarantee. The reliability,
> > scalability, fault tolerance and performance has been well proven in
> global
> > large scale revenue supporting production system in Yahoo.
> >
> > As a distributed computation system, it’s an innovative model where the
> > compute layer is introduced on top of the storage layer natively and
> > naturally to optimize the data locality of computation.
> >
> > Operating the project in “apache way” greatly aligns with the long-term
> > vision of this project and can greatly help the development of the
> > community.
> >
> > == Current Status ==
> >
> > Pistachio was open-sourced and announced in April 2015 and currently
> being
> > hosted in Github, it was mainly being developed by the team from Yahoo
> and
> > already attracted lots of external developers (20+ watches and forks on
> > github).
> >
> > == Meritocracy ==
> >
> > We plan to build an environment following the Apache meritocracy
> > principles. Many companies including Linkedin, GF securities, Microsoft
> and
> > open source communities like deeplearning4j have already expressed
> > interests or accepted the invitations to participate in this project.
> >
> > == Community ==
> >
> > Since the announcement of Pistachio we received lots of interests. And
> the
> > concept of embedding computation to storage also got lots of
> recognitions.
> > We also started to work with other communities like deeplearning4j to
> build
> > more application use cases with Pistachio. We believe the community will
> > grow fast.
> >
> > == Core Developers ==
> >
> > This project is created by Gavin Li. Core developers are currently mainly
> > in Yahoo.
> >
> > == Alignment ==
> >
> > Pistachio depends on many Apache projects and dependencies including
> Kafka,
> > Helix, Zookeeper, Curator, Apache Commons, etc.
> >
> > == Known Risks ==
> >
> > === Orphaned Products ===
> >
> > The risk of Pistachio being orphaned is small because Yahoo heavily
> > invested in this sys

Re: [PROPOSAL]Pistachio

2015-06-22 Thread Andrew Purtell
It was a simple question, and not meant to suggest anything one way or
other regarding my opinion of this proposal.

On Monday, June 22, 2015, John D. Ament  wrote:

> On Mon, Jun 22, 2015 at 10:26 PM Andrew Purtell  > wrote:
>
> > > Pistachio can easily embed computation to the storage layer to achieve
> > the
> > > best data locality to improve the computation performance significantly
> > > which is an innovative model comparing with the normal ways where the
> > > storage and compute are independent to each other.
> >
> > Have you heard of something called Hadoop?
> >
>
> Regardless of whether he has or not - what's your point? The ASF has
> historically not denied the entry of new projects just because their domain
> intersects with another project's.
>
>
> >
> >
> > On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  > wrote:
> >
> > > Hi,
> > >
> > > I want to propose project Pistachio to enter Apache Incubator.
> > >
> > > Below please find the proposal.
> > >
> > > Thanks,
> > > Gavin Li
> > >
> > >
> > >
> > > = Pistachio =
> > >
> > > == Abstract ==
> > >
> > > Pistachio is a fault-tolerant low latency distributed storage system
> > which
> > > enables simple embedding the computation to the storage layer to
> achieve
> > > best data locality. It evolves from Yahoo’s global user profile storage
> > > system.
> > >
> > > == Proposal ==
> > >
> > > Pistachio is a distributed key value store system with fault tolerance
> > and
> > > consistency guarantee. It supports multiple local storage engine
> > including
> > > in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as the
> > user
> > > profile storage for massive scale global ads products in Yahoo storing
> > 10+
> > > billion user profiles. The performance and reliability has been well
> > proven
> > > on production.
> > >
> > > Pistachio can easily embed computation to the storage layer to achieve
> > the
> > > best data locality to improve the computation performance significantly
> > > which is an innovative model comparing with the normal ways where the
> > > storage and compute are independent to each other.
> > >
> > > == Background ==
> > >
> > > Pistachio is originally designed and optimized for Yahoo’s large scale
> > > global open RTB(real-time bidding) use cases where latency is
> > critical(the
> > > whole request needs to be finished within 100ms including network round
> > > trips). It stores 10+ billion user profiles in 8 data centers.
> > >
> > > Then because of the great performance and the flexibility of local
> > storage
> > > choices, we evolved it to do distributed compute. Rich call back
> > interfaces
> > > are added to supports easy compute directly on top of the storage
> system
> > > local to the data partition. This model is totally different from the
> > > traditional distributed computation model where the storage and compute
> > are
> > > separated and independent. In the new model we found data locality can
> be
> > > improved significantly and lots of data access round trips can be
> reduced
> > > in computation, and the performance can be improved significantly.
> > >
> > > It was publicly announced in April 2015 and currently being hosted in
> > > Github.
> > >
> > > == Rationale ==
> > >
> > > As a key value store system Pistachio is unique in terms of low latency
> > > access with fault tolerance and consistency guarantee. The reliability,
> > > scalability, fault tolerance and performance has been well proven in
> > global
> > > large scale revenue supporting production system in Yahoo.
> > >
> > > As a distributed computation system, it’s an innovative model where the
> > > compute layer is introduced on top of the storage layer natively and
> > > naturally to optimize the data locality of computation.
> > >
> > > Operating the project in “apache way” greatly aligns with the long-term
> > > vision of this project and can greatly help the development of the
> > > community.
> > >
> > > == Current Status ==
> > >
> > > Pistachio was open-sourced and announced in April 2015 and currently
> > being
> > > hosted in Github, it was mainly being developed by the team from Yahoo
> > and
> > > already attracted lots of external developers (20+ watches and forks on
> > > github).
> > >
> > > == Meritocracy ==
> > >
> > > We plan to build an environment following the Apache meritocracy
> > > principles. Many companies including Linkedin, GF securities, Microsoft
> > and
> > > open source communities like deeplearning4j have already expressed
> > > interests or accepted the invitations to participate in this project.
> > >
> > > == Community ==
> > >
> > > Since the announcement of Pistachio we received lots of interests. And
> > the
> > > concept of embedding computation to storage also got lots of
> > recognitions.
> > > We also started to work with other communities like deeplearning4j to
> > build
> > > more application use cases with Pistachio. We believe the community
> will
> > > grow fast.
> > >
> > > == Cor

Re: [PROPOSAL]Pistachio

2015-06-22 Thread Roman Shaposhnik
On Mon, Jun 22, 2015 at 7:45 PM, John D. Ament  wrote:
> On Mon, Jun 22, 2015 at 10:26 PM Andrew Purtell  wrote:
>
>> > Pistachio can easily embed computation to the storage layer to achieve
>> the
>> > best data locality to improve the computation performance significantly
>> > which is an innovative model comparing with the normal ways where the
>> > storage and compute are independent to each other.
>>
>> Have you heard of something called Hadoop?
>>
>
> Regardless of whether he has or not - what's your point? The ASF has
> historically not denied the entry of new projects just because their domain
> intersects with another project's.

You're both right ;-) My takeaway from Andrew's comment was that
this is surely a statement that needs to be clarified. There are different
clarifications possible of course: ranging from "let us show Hadoop how
to do it" all the way to "Hadoop/Spark/etc are solving a different problem
here's how it is different".

Thanks,
Roman.

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



Re: [PROPOSAL]Pistachio

2015-06-22 Thread Gavin Li
Hi Andrew,

As we described more in
http://yahooeng.tumblr.com/post/116291838351/pistachio-co-locate-the-data-and-compute-for,
a very common problem we saw in Hadoop use cases is we often need to
persist the previous result of one map reduce job onto HDFS, then the next
day we process the new data together with the previous result. Usually the
most expensive part is the shuffling part where we need to join the
previous data and the new data together. It's so expensive because HDFS
doesn't store the data in a partitioned way. So data have to be transferred
again and again in the shuffling phase. Instead, in Pistachio we do the
computation right on top of the partitioned storage layer, so that the
previous result is always stored in a partitioned way, so shuffling can be
avoided. Expensive IO and roundtrips can thus be avoided so that much
better performance can be achieved.

The other difference is in Pistachio we can do computation based on
in-memory storage with data replication. Different from the in-memory
computation in Spark, the storage can be in-memory here.

Please let me know if I'm not clear enough.

Thanks,
Gavin Li

On Mon, Jun 22, 2015 at 7:53 PM, Andrew Purtell  wrote:

> It was a simple question, and not meant to suggest anything one way or
> other regarding my opinion of this proposal.
>
> On Monday, June 22, 2015, John D. Ament  wrote:
>
> > On Mon, Jun 22, 2015 at 10:26 PM Andrew Purtell  > > wrote:
> >
> > > > Pistachio can easily embed computation to the storage layer to
> achieve
> > > the
> > > > best data locality to improve the computation performance
> significantly
> > > > which is an innovative model comparing with the normal ways where the
> > > > storage and compute are independent to each other.
> > >
> > > Have you heard of something called Hadoop?
> > >
> >
> > Regardless of whether he has or not - what's your point? The ASF has
> > historically not denied the entry of new projects just because their
> domain
> > intersects with another project's.
> >
> >
> > >
> > >
> > > On Thu, Jun 18, 2015 at 10:17 AM, Gavin Li  > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I want to propose project Pistachio to enter Apache Incubator.
> > > >
> > > > Below please find the proposal.
> > > >
> > > > Thanks,
> > > > Gavin Li
> > > >
> > > >
> > > >
> > > > = Pistachio =
> > > >
> > > > == Abstract ==
> > > >
> > > > Pistachio is a fault-tolerant low latency distributed storage system
> > > which
> > > > enables simple embedding the computation to the storage layer to
> > achieve
> > > > best data locality. It evolves from Yahoo’s global user profile
> storage
> > > > system.
> > > >
> > > > == Proposal ==
> > > >
> > > > Pistachio is a distributed key value store system with fault
> tolerance
> > > and
> > > > consistency guarantee. It supports multiple local storage engine
> > > including
> > > > in-memory, kyoto cabinet, rocks DB etc. Pistachio is being used as
> the
> > > user
> > > > profile storage for massive scale global ads products in Yahoo
> storing
> > > 10+
> > > > billion user profiles. The performance and reliability has been well
> > > proven
> > > > on production.
> > > >
> > > > Pistachio can easily embed computation to the storage layer to
> achieve
> > > the
> > > > best data locality to improve the computation performance
> significantly
> > > > which is an innovative model comparing with the normal ways where the
> > > > storage and compute are independent to each other.
> > > >
> > > > == Background ==
> > > >
> > > > Pistachio is originally designed and optimized for Yahoo’s large
> scale
> > > > global open RTB(real-time bidding) use cases where latency is
> > > critical(the
> > > > whole request needs to be finished within 100ms including network
> round
> > > > trips). It stores 10+ billion user profiles in 8 data centers.
> > > >
> > > > Then because of the great performance and the flexibility of local
> > > storage
> > > > choices, we evolved it to do distributed compute. Rich call back
> > > interfaces
> > > > are added to supports easy compute directly on top of the storage
> > system
> > > > local to the data partition. This model is totally different from the
> > > > traditional distributed computation model where the storage and
> compute
> > > are
> > > > separated and independent. In the new model we found data locality
> can
> > be
> > > > improved significantly and lots of data access round trips can be
> > reduced
> > > > in computation, and the performance can be improved significantly.
> > > >
> > > > It was publicly announced in April 2015 and currently being hosted in
> > > > Github.
> > > >
> > > > == Rationale ==
> > > >
> > > > As a key value store system Pistachio is unique in terms of low
> latency
> > > > access with fault tolerance and consistency guarantee. The
> reliability,
> > > > scalability, fault tolerance and performance has been well proven in
> > > global
> > > > large scale revenue supporting production system in Yahoo.
> > > >
> 

Re: [PROPOSAL]Pistachio

2015-06-22 Thread Roman Shaposhnik
On Mon, Jun 22, 2015 at 7:54 PM, Gavin Li  wrote:
> The other difference is in Pistachio we can do computation based on
> in-memory storage with data replication. Different from the in-memory
> computation in Spark, the storage can be in-memory here.

Have you guys looked at in-memory computation layers offered by
Ignite and Geode? I would love to know what you think about those.

Thanks,
Roman.

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



Re: [PROPOSAL]Pistachio

2015-06-22 Thread Gavin Li
Roman,

I think Pistachio is similar to Ignite in the sense that they both try to
distribute the computation to storage to co-locate the data and
computation. One difference might be Pistachio also supports other storage
options like disk based storage to support longer term durability. Actually
Pistachio was originally developed as a storage system of SSD disk and has
been used on our large scale production serving system with SSD disk.

We're not that familiar with Geode, I'll look into it and provide some
detailed comparisons.

Thanks,
Gavin Li



On Mon, Jun 22, 2015 at 8:00 PM, Roman Shaposhnik 
wrote:

> On Mon, Jun 22, 2015 at 7:54 PM, Gavin Li  wrote:
> > The other difference is in Pistachio we can do computation based on
> > in-memory storage with data replication. Different from the in-memory
> > computation in Spark, the storage can be in-memory here.
>
> Have you guys looked at in-memory computation layers offered by
> Ignite and Geode? I would love to know what you think about those.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


Re: [VOTE] Release Apache Usergrid 1.0.2 (incubating) RC2

2015-06-22 Thread Justin Mclean
Hi,

Sorry but it -1 binding until the font licenses had been sorted.

I checked:
- signatures and hashes correct
- artefact has incubating in it’s name
- DISCLAIMER exists
- LICENSE and NOTICE ok - a couple of minor issues see below
- no unexpected binaries in release
- all source files have headers
- can compile from source

These files:
./portal/css/arsmarquette/ARSMaquettePro-Light.otf
./portal/css/arsmarquette/ARSMaquettePro-Medium.otf
./portal/css/arsmarquette/ARSMaquettePro-Regular.otf

As far as I can tell are:
Copyright (c) ARS Type®-Angus R. Shamal, 1999-2010. All rights reserved.

And not licensed under an Apache compatible license. Is this correct?

Looks like this had already been raised as an issue (and quite a while ago):
https://issues.apache.org/jira/browse/USERGRID-238

Minor issues:
- Having a little more information in the LICENSE  file re version 
numbers/copyright holders and URLs while not legally required would be helpful.
- NOTICE is missing year, please add this for next release.
- LICENSE seems to be missing jQuery sparklines (BSD) (See 
./portal/js/libs/jquery/jquery.sparkline.min.js)

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



[DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

2015-06-22 Thread Roman Shaposhnik
Hi!

let me start by saying that I feel proud about the
rigor with which ASF approaches management
of the ultimate foundation deliverables: the source
releases put out by our communities. If you read our
policy document:
http://www.apache.org/dev/release.html
and only focus on the source releases it is obvious
to me that we strike a great balance between fostering
innovation while practicing strict IP hygiene.

Unfortunately, I can't really say the same for the parts
of the policy that covers binary convenience artifacts.
The way our policy talks about these artifacts seems to
invite different interpretations which is especially
problematic for training podlings in the "Apache Way"
(hence even though this discussion is perfectly applicable
to TLPs I'm starting it here on general@incubator).

The biggest source of confusion that I personally witnessed
comes from interpreting 'general public' vs. 'developers'.
The problem there seems to come from the false assumption
that our projects always have a user base that is non-developer
in nature. For projects like libraries or frameworks this is simply
not the case. The end-users of such projects are always, by
definition, developers.

Think of them as downstream developers integrating with ASF
projects via binary artifacts. These folks always embed ASF
project into larger systems. They also, typically, live and die
by the level of API compatibility that the upstream ASF-produced
dependencies maintain. This, in turn, puts pressure on ASF
upstream projects to maintain a healthy and convenient channel
for managing non-release, downstream integration binary artifacts.
Unfortunately, our current release policy is extremely confusing when
it comes to this very important use case. What's worse, in my opinion
it gets in the way of fostering user community for projects where
users == downstream developers.

How am I supposed to invite all the downstream developers of the
world to start integrating with my awesome feature FOO before it
gets formally released when our policy makes statement like:
"If the general public is being instructed to download a package,
then that package has been released."

Are we really suggesting that I can not present at conference, tweet
and otherwise promote the awesomeness of my project based on
'what's coming'? I've always assumed that we are not and the way
policy is currently worded is just sloppy.

I know that there's been a number of threads over the years that tilted
at the windmill of clarifying our policies around binary releases. At this
point, I'm actually taking a step back and asking a bigger question: why
don't we take a more nuanced approach towards the very issue of
what makes a release a release.

IOW, I would like to focus on answering the question of how can we
empower our communities to effectively communicate *their* intent
of how *they* expect an artifact to be consumed.

After all, we have a really good way of communicating that type of intent
when it comes to branding: if you want to communicate that Apache
FOO is a poddling you MUST refer to it as Apache FOO (incubating).
Simple and effective. Exact opposite of our release policy that seems
to completely discount labeling for communicating intent. I'm sorry,
but a -SNAPSHOT labeling of a version ID communicates as much
(if not more) to me as a writing on a website does. Lets just recognize
that.

Thanks,
Roman.

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



Re: [VOTE] Apache Ignite 1.2.0 release (RC2)

2015-06-22 Thread Justin Mclean
Hi,

Sorry -1 binding due to binary files in the source release. Will change my vote 
if there's a good reason for this or if I’m mistaken.

I checked:
- release contains incubating
- DISCLAIMER exists
- LICENSE and NOTICE good
- Possible unexpected binary (see below)
- All source files have Apache headers
- Can compile from source

I notice a few .gar in the source release. These are similar to .war files 
right?
./modules/core/src/test/resources/helloworld.gar
./modules/core/src/test/resources/helloworld1.gar
./modules/extdata/p2p/deploy/p2p.gar
./modules/extdata/uri/deploy/uri.gar

The test files are probably OK, but the deploy files seem like they shouldn't 
be there.

The LICENSE and NOTICE for the binary files also look incorrect give the number 
of jars and lack of information in LICENSE / NOTICE. This will need to be fixed 
at some point before graduation. See [1] for more info. The LICENSE/NOTICE 
files should be different for the binaries and reflect their contents.

I’ve not looked at the the binaries in detail but from a quick look / picking a 
few jar at random I see:
- jsch-0.1.50.jar is BSD so that would need to be added to binary LICENSE.
- docker-1.9.0.jar if it;s docker then, while docker is Apache licensed it has 
a NOTICE file [2], so that would need to be added to the binary NOTICE file.
- avax.servlet-api-3.0.1.jar may be problematic as it is CDDL + GPLv2. If this 
is an optional dependancy if may need to be downloaded separately.

Your mentors should be able to help with what needed here or email here if the 
need a hand assembling / checking before you make a release. The best guidance 
can be found at [3]. Keep in mind the guiding principal [4] and it’s mostly 
straight forward.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#binary
2. https://github.com/docker/docker/blob/master/NOTICE
3. http://www.apache.org/dev/licensing-howto.html
4. http://www.apache.org/dev/licensing-howto.html#guiding-principle
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

2015-06-22 Thread Marvin Humphrey
On Mon, Jun 22, 2015 at 9:06 PM, Roman Shaposhnik  wrote:

> The biggest source of confusion that I personally witnessed
> comes from interpreting 'general public' vs. 'developers'.
> The problem there seems to come from the false assumption
> that our projects always have a user base that is non-developer
> in nature. For projects like libraries or frameworks this is simply
> not the case. The end-users of such projects are always, by
> definition, developers.

The distinction is between people who develop the Apache product, and
those who use the Apache product.

> How am I supposed to invite all the downstream developers of the
> world to start integrating with my awesome feature FOO before it
> gets formally released when our policy makes statement like:
> "If the general public is being instructed to download a package,
> then that package has been released."

Rather than invite them in before you make a release, why not release
first and then invite them in?

> Are we really suggesting that I can not present at conference, tweet
> and otherwise promote the awesomeness of my project based on
> 'what's coming'?

Why not release before presenting, tweeting, or promoting?

> IOW, I would like to focus on answering the question of how can we
> empower our communities to effectively communicate *their* intent
> of how *they* expect an artifact to be consumed.

They can communicate their intent by voting on a release.

> After all, we have a really good way of communicating that type of intent
> when it comes to branding: if you want to communicate that Apache
> FOO is a poddling you MUST refer to it as Apache FOO (incubating).
> Simple and effective. Exact opposite of our release policy that seems
> to completely discount labeling for communicating intent. I'm sorry,
> but a -SNAPSHOT labeling of a version ID communicates as much
> (if not more) to me as a writing on a website does. Lets just recognize
> that.

If artifacts are being consumed by people other than those who develop
the Apache product, those artifacts need to be vetted and voted.

Marvin Humphrey

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