Re: [PROPOSAL] Heron

[P. Taylor Goetz]

Hi Bill,

Could you comment on how/if the Heron community would be willing to work with 
the Storm community? I've seen a number of new features in Storm being ported 
to Heron, but I have yet to see any attempt by the Heron community to engage 
with the Apache Storm community.

I don't think it would be too far off to say that the relationship between 
Heron and Apache Storm has been somewhat adversarial. The pre- and post-open 
sourcing marketing around Heron seemed, at least to me, somewhat aggressively 
negative toward Storm.

As a peer to Apache Storm, how would the proposed "Apache Heron" community work 
to collaborate with the Storm community? If Heron is adopting API changes in 
Storm, then it seems there is an opportunity for collaboration.

Don't take any of this as an objection to incubating the project. I would 
support it. I would also be willing to be a mentor, if you would consider 
taking on another.

-Taylor

> On Jun 8, 2017, at 1:23 PM, Bill Graham  wrote:
> 
> Dear Apache Incubator Community,
> 
> We are excited to share our proposal for discussion and feedback
> for entering Apache Incubation. Heron is a real-time, distributed,
> fault-tolerant stream processing engine.
> 
> Our proposal can be found at https://wiki.apache.org/incubator/HeronProposal
> and is included below.
> 
> 
> Thank you,
> 
> Bill Graham on behalf of the Heron developers
> 
> 
> # Heron Proposal
> 
> ## Abstract
> Heron is a real-time, distributed, fault-tolerant stream processing engine
> initially developed by Twitter.
> 
> ## Proposal
> 
> Heron is a real-time stream processing engine built for high performance,
> ease of manageability, performance predictability and developer
> productivity[1]. We wish to develop a community around Heron to increase
> contributions and see Heron thrive in an open forum.
> 
> ## Background
> 
> Heron provides the ability for developers to compose directed acyclic
> graphs (DAGs) of real-time query execution logic (i.e. a topology) and
> submit the topology to execute on a pluggable job scheduling system (e.g.,
> Apache Aurora, YARN, Marathon, etc). Users can employ either the native
> Heron API or the Apache Storm API to develop the topology. Heron supports
> the Storm API for ease of migration, but beyond that Heron’s architecture
> differs considerably from Storm’s.
> 
> Users submit a topology to the scheduler using the Heron client, which uses
> the Heron binary libraries to deploy all daemons required to run and manage
> the topology. The topology therefore has no reliance on centrally managed
> Heron services, only on a generic job scheduling system, which lends itself
> well to be run on top of Apache Aurora/Mesos or Apache Hadoop/YARN (among
> others).
> 
> The scheduler runs each topology as a job consisting of multiple
> containers. One of the containers runs the topology master, responsible for
> managing the topology. The remaining containers each runs a stream manager
> responsible for data routing, a metrics manager that collects and reports
> various metrics and a number of processes called Heron instances which run
> the user-defined logic on the stream of tuples. Parallelism is achieved via
> process-based isolation of Heron instances, which provides predictable
> performance while simplifying debugging. The containers are allocated and
> managed by the scheduler framework based on resource availability of nodes
> in the cluster. The metadata for the topology, such as the physical plan
> and execution details, are stored in the pluggable Heron State Manager
> (e.g. Apache ZooKeeper).
> 
> ## Rationale
> 
> Heron is a general-purpose, modular and extensible platform that can be
> leveraged to support common, real-time analytics use cases. There is an
> increasing demand for open-source, scalable real-time analytics systems. We
> believe that Heron can be leveraged by other organizations to build
> streaming applications that can benefit from its robustness, high
> performance, adaptability to cloud environments and ease of use. Moreover,
> we hope that open-sourcing Heron will help to further evolve the technology
> as the project attracts contributors with diverse backgrounds and areas of
> expertise.
> 
> We believe the Apache foundation is a great fit as the long-term home for
> Heron, as it provides an established process for community-driven
> development and decision making by consensus. This is exactly the model we
> want for future Heron development.
> 
> ## Initial Goals
> 
> * Move the existing codebase, website, documentation, and mailing lists to
> Apache-hosted infrastructure.
> * Integrate with the Apache development process.
> * Ensure all dependencies are compliant with Apache License version 2.0.
> * Incrementally develop and release per Apache guidelines.
> 
> ## Current Status
> 
> Heron is a stable project used in production at Twitter since 2014 and open
> sourced under the ASL v2 license in 2016. The Heron source 

Re: [VOTE] - Approve the release of Apache Joshua incubating 6.1 (rc4)

[John D. Ament]

Here's my +1 for the release.

We may have to be a bit diligent on an issue like this, but can be resolved
after this release.

On Fri, Jun 9, 2017 at 10:20 PM Justin Mclean 
wrote:

> Hi,
>
> > @justin, if you are interested in continuing to help Joshua incubating
> with
> > the release process then pleae stick with us until we iron this one out.
>
> I’ve already voted +1 on the release.
>
> That GitHub issue looks resolved to me i.e. the copyright owner gave you
> permission to use the code under an Apache license.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: svn commit: r1798292 - /incubator/public/trunk/content/podlings.xml

[John D. Ament]

All,

Please note the below.  For any project that was missing the days in their
start or end date, I have added a best guess day.  I'm happy to make
further changes to the dates and would encourage others if they see issues
and have more concrete information.

John

On Fri, Jun 9, 2017 at 10:17 PM  wrote:

> Author: johndament
> Date: Sat Jun 10 02:17:25 2017
> New Revision: 1798292
>
> URL: http://svn.apache.org/viewvc?rev=1798292=rev
> Log:
> Adding best guess podling dates including day of month.
>
> Modified:
> incubator/public/trunk/content/podlings.xml
>
> Modified: incubator/public/trunk/content/podlings.xml
> URL:
> http://svn.apache.org/viewvc/incubator/public/trunk/content/podlings.xml?rev=1798292=1798291=1798292=diff
>
> ==
> --- incubator/public/trunk/content/podlings.xml [utf-8] (original)
> +++ incubator/public/trunk/content/podlings.xml [utf-8] Sat Jun 10
> 02:17:25 2017
> @@ -609,7 +609,7 @@ and a set of useful extensions for this
>  Nicola Ken Barozzi
>  
>  
> - sponsor="DB" startdate="2004-08-15" enddate="2005-07">
> + sponsor="DB" startdate="2004-08-15" enddate="2005-07-18">
>  Java relational database
>  http://db.apache.org/derby/"/>
>  
> @@ -1154,7 +1154,7 @@ and a set of useful extensions for this
>  Roy T. Fielding
>  
>  
> - sponsor="Web Services" startdate="2003-09" enddate="2004-03">
> + sponsor="Web Services" startdate="2003-09-15" enddate="2004-03-17">
>  Implementation of JAXB, the specification for
> Java/XML binding
>  http://ws.apache.org/jaxme/"/>
>  
> @@ -1225,7 +1225,7 @@ and a set of useful extensions for this
>  Sam Ruby
>  
>  
> - sponsor="Web Services" startdate="2003-09" enddate="2004-03">
> + sponsor="Web Services" startdate="2003-09-15" enddate="2004-03-17">
>  Implementation of a Universal Description Discovery
> and Integration (UDDI) registry
>  
>  
> @@ -1347,7 +1347,7 @@ and a set of useful extensions for this
>  Jean-Baptiste Onofre
>  
>  
> - sponsor="Cocoon" startdate="2003-03" enddate="2004-08">
> + sponsor="Cocoon" startdate="2003-03-15" enddate="2004-08-18">
>  Content Management and publishing system based on
> Cocoon
>  
>  
> @@ -1391,7 +1391,7 @@ and a set of useful extensions for this
>  Ralph Goers
>  
>  
> - sponsor="Logging Services" startdate="2004-01" enddate="2007-02">
> + sponsor="Logging Services" startdate="2004-01-15" enddate="2007-02-21">
>  Logging for .NET
>  http://logging.apache.org/log4net/"/>
>  
> @@ -1472,7 +1472,7 @@ and a set of useful extensions for this
>  Andy Seaborne
>  
>  
> - resource="merlin-developer" sponsor="Avalon" startdate="2004-01"
> enddate="2004-01">
> + resource="merlin-developer" sponsor="Avalon" startdate="2004-01-15"
> enddate="2004-01-15">
>  Merlin eclipse plugin merged with an existing
> eclipse plugin already at avalon.
>  
>  Leo Simons
> @@ -1529,7 +1529,7 @@ and a set of useful extensions for this
>  Henry Saputra
>  
>  
> - sponsor="HTTP Server" startdate="2005-08-06" enddate="2007-02">
> + sponsor="HTTP Server" startdate="2005-08-06" enddate="2007-02-21">
>  FTP protocol module for Apache httpd
> 2.x
>  http://httpd.apache.org/mod_ftp/"/>
>  
> @@ -1646,7 +1646,7 @@ and a set of useful extensions for this
>  Konstantin Boudnik
>  
>  
> - sponsor="Incubator" startdate="2005-01" enddate="2005-06-01">
> + sponsor="Incubator" startdate="2005-01-15" enddate="2005-06-01">
>  Web search software.
>  
>  
> @@ -2036,7 +2036,7 @@ and a set of useful extensions for this
>  Upayavira
>  
>  
> - startdate="2007-04-06" enddate="2009-09">
> + startdate="2007-04-06" enddate="2009-09-15">
>  JSF Component Library.
>  Never got started, so retired.
>  
> @@ -2688,7 +2688,7 @@ top of Apache HBase and other storage en
>  Radu Preotiuc-Pietro
>  
>  
> - sponsor="Geronimo" startdate="2005-12-05" enddate="2005-12">
> + sponsor="Geronimo" startdate="2005-12-05" enddate="2005-12-05">
>  a robust hetorgeneous clustering engine used to
> cluster geronimo, tomcat, jetty and other containers
> eventually.
>  Proposal withdrawn by creator; project continues at
> Codehaus.
>  
> @@ -2703,7 +2703,7 @@ top of Apache HBase and other storage en
>  Upayavira
>  
>  
> - sponsor="Struts" startdate="2006-01" enddate="2006-05">
> + sponsor="Struts" startdate="2006-01-15" enddate="2006-05-24">
>  A Java web-application 

Re: [VOTE] - Approve the release of Apache Joshua incubating 6.1 (rc4)

[Justin Mclean]

Hi,

> @justin, if you are interested in continuing to help Joshua incubating with
> the release process then pleae stick with us until we iron this one out.

I’ve already voted +1 on the release. 

That GitHub issue looks resolved to me i.e. the copyright owner gave you 
permission to use the code under an Apache license.

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

Re: [VOTE] - Approve the release of Apache Joshua incubating 6.1 (rc4)

[lewis john mcgibbney]

Hi Folks,
We are making progress here folks.
@justin, if you are interested in continuing to help Joshua incubating with
the release process then pleae stick with us until we iron this one out.
Thank you
Lewis

On Mon, Jun 5, 2017 at 2:28 PM, lewis john mcgibbney 
wrote:

> Please see the following issue folks
> https://github.com/redpony/cdec/issues/94
> Thanks
> Lewis
>
> On Fri, Jun 2, 2017 at 9:46 AM, lewis john mcgibbney 
> wrote:
>

Re: [VOTE] Apache Fluo 1.1.0-incubating (rc1)

[Christopher]

Ping IPMC to take a look at this release candidate from Fluo. It currently
has only one +1 from carried over from PPMC vote by mentor, and no other
votes.

On Wed, Jun 7, 2017 at 6:48 PM sebb  wrote:

> On 7 June 2017 at 23:36, Christopher  wrote:
> > On Wed, Jun 7, 2017 at 5:28 PM sebb  wrote:
> >
> >> On 7 June 2017 at 01:59, Christopher  wrote:
> >> > On Tue, Jun 6, 2017 at 6:47 PM sebb  wrote:
> >> >
> >> >> On 6 June 2017 at 23:38, Christopher  wrote:
> >> >> > On Tue, Jun 6, 2017 at 6:29 PM sebb  wrote:
> >> >> >
> >> >> >> On 6 June 2017 at 23:25, Christopher  wrote:
> >> >> >> > On Tue, Jun 6, 2017 at 6:03 PM sebb  wrote:
> >> >> >> >
> >> >> >> >> On 6 June 2017 at 21:15, Keith Turner 
> wrote:
> >> >> >> >> > Dear IPMC,
> >> >> >> >> >
> >> >> >> >> > Please vote for the following release candidate of Apache
> Fluo
> >> >> >> >> > 1.1.0-incubating.
> >> >> >> >> >
> >> >> >> >> > PPMC vote thread:
> >> >> >> >> >
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/c815b7a22fab10281ab2d4e88418a47a5903ba85327058bb727c7ccd@%3Cdev.fluo.apache.org%3E
> >> >> >> >> >
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> https://lists.apache.org/thread.html/99508ef4a2b782b82494e4250713c1d0917b75cf7149bec64455bea2@%3Cdev.fluo.apache.org%3E
> >> >> >> >> >
> >> >> >> >> > Staged dist artifacts:
> >> >> >> >> >
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo/1.1.0-incubating-rc1/
> >> >> >> >>
> >> >> >> >> The hashes need to be in individual files, like the signature
> >> (.asc)
> >> >> >> >> [You can probably copy the corresponding ones from the Maven
> >> repo.]
> >> >> >> >>
> >> >> >> >> AFAIK the MD5SUM and SHA1SUM files should not be present.
> >> >> >> >>
> >> >> >> >> I'm not sure the .gitignore files should be there.
> >> >> >> >>
> >> >> >> >>
> >> >> >> >
> >> >> >> > I believe the *SUM files have been discussed before. I do not
> >> believe
> >> >> it
> >> >> >> to
> >> >> >> > be an issue, as INFRA excludes these from mirroring in the same
> >> way as
> >> >> >> > other files, and they are convenient.
> >> >> >>
> >> >> >> But the individual has files are still required.
> >> >> >>
> >> >> >>
> >> >> > Required by what policy?
> >> >> >
> >> >>
> >> >> http://www.apache.org/dev/release-distribution.html#sigs-and-sums
> >> >>
> >> >>
> >> >
> >> > Thanks.
> >> >
> >> > That's interesting. The current wording seems like a technical
> >> requirement
> >> > for the mirror distribution process. It seems like the intent (though,
> >> hard
> >> > to know for sure) was to follow a pattern that would ensure hashes
> aren't
> >> > mirrored.
> >>
> >> AIUI that is partly the case.
> >> AFAIK there's also the expectation that consumers will be able to use
> >> a standard name for the hashes and sigs.
> >>
> >>
> >
> > I wouldn't have thought INFRA would be in the business of managing
> consumer
> > expectations. Seems like a PMC responsibility, at the individual
> community
> > level, to me.
> >
> >
> >> > However, it is currently inconsistent with the actual behavior of
> >> > the mirror distribution process and also seems to apply to all other
> >> > infra-supported channels like Nexus. It also seems to be regularly
> >> > violated, since there are a *LOT* of projects which use variants,
> such as
> >> > ".sha1" or ".sha256" or ".sha512" or ".mds" in dist/release.
> >>
> >> Does not make it right; AFAIK many such variants are excluded from
> synch.
> >>
> >>
> >
> > In anticipation of this response, I've already conceded this point. ;)
> > As I said, it's merely a strong indication that the page isn't accurately
> > documenting the policy being enforced.
> >
> >
> >> > Also, every
> >> > Maven artifact deployed to Nexus is also in violation.
> >>
> >> Nexus (i.e. staging for the Maven repo) has separate rules.
> >>
> >>
> > The policy you cite specifically says "Every artifact distributed to the
> > public through Apache channels". The wording doesn't allow for
> differences
> > between system-specific channels.
>
> AFAIK the Maven repo is not an Apache channel.
>
> > If we're going by system-specific guidance, then I don't understand your
> > original objection, because SHA1SUM and MD5SUM files are explicitly
> > mentioned in the system-specific guidance for "normal distribution"
> through
> > the mirrors
> > http://www.apache.org/dev/release-publishing.html#distribution_dist ,
> just
> > as .sha1 is explicitly mentioned in the Maven publication guidance
> (linked
> > in the section which immediately follows the "normal distribution"
> section).
>
> I had not read that recently.
>
> > I'm assuming the basis of the objection was that the global INFRA policy
> > supersedes system-specific guidance. If that's not the case, then I'm
> very
> > confused 

[RESULT][VOTE] Graduate Apache Atlas Project from Incubator

[Suma Shivaprasad]

Dear Incubator members,

It has been more that 72 hours since I started this VOTE thread, so I
consider this voting thread as closed. Thanks to incubator members and
mentors for voting.

Here is the result

8 [+1] Votes  ( 5 binding votes , 3 non-binding votes )

Binding Votes:
==

John D Ament    (binding)
Suneel Marthi   (binding)
Julian Hyde (binding)
Christopher Douglas >(binding)
Jean-Baptiste Onofré   (binding)


Non-Binding Votes:
==

Pierre Smits   (non-binding)
Balaji Ganesan(non-binding)
Suma Shivaprasad>(non-binding)

The vote to graduate Atlas from incubator to a TLP has successfully passed
with

5 +1 binding votes, 3 non-binding
and no 0/-1 votes

Thanks
Suma

Re: [VOTE] Merge DistributedLog as the subproject of Apache BookKeeper

[Uma gangumalla]

+1 (binding)

Regards,
Uma

On Thu, Jun 8, 2017 at 5:21 PM, Sijie Guo  wrote:

> ( /cc bookkeeper dev@ and incubator general@ for awareness )
>
> Hi all,
>
> There was a joint discussion between BookKeeper PMC and DistributedLog PPMC
> about moving the development of DistributedLog as part of Apache
> BookKeeper. The reasons behind it are:
>
> First, DistributedLog is born as an extension to BookKeeper, to offer
> continuous log streams as the service. The ledger API in bookkeeper is a
> lower level API and has learning curves, while the log stream API in
> distributedlog is a higher level API that simplifies the usage. The
> combination of ledger API and stream API would offer a better
> developer/user experience for applications.
>
> Secondly, using ledgers to build continuous (re-openable) log stream is a
> very common pattern for BookKeeper use cases. We did this for HDFS namenode
> journal, for Hedwig, for DistributedLog, and for Pulsar. The same pattern
> has been implemented again and again. Merge DistributedLog (also
> ManagedLedger in Pulsar) with BookKeeper will consolidate all the
> development efforts around this common 'log stream' pattern.
>
> Thirdly, the 'log' stream abstraction is a good abstraction for both
> messaging and streaming. Internally at BookKeeper, there are a few places
> that can use such 'messaging' facility to improve bookkeeper itself. the
> log stream in DistributedLog can be used internally at bookkeeper for
> streaming changes as well.
>
> We choose merging DistributedLog as subproject rather than modules. It is a
> softer starting point to avoid disrupting the folks who are depending on
> the ledger api alone. The BookKeeper PMC and DistributedLog PPMC has
> achieved initial consensus on this merge. There is an official VOTE ongoing
> in bookkeeper PMC. We'd like to bring this to the distributedlog community
> for a community vote following the guidelines here
> .
>
> Please vote +1 if in favor of merging DistributedLog to BookKeeper, and -1
> if not. The vote will be open until Tuesday 13rd June, 18:00 PST.
>
> - Sijie
>

Re: [PROPOSAL] Heron

[Bill Graham]

Thanks Supun. The main commonality with Storm is that Heron implements the
Storm user-facing API for developing topologies. Besides that the
architecture is completely different (no central services, full isolation
at the process, task and topology levels, pluggable scheduler, etc). The
key unique elements of the Heron architecture are described in paragraphs 2
and 3 of Background section.

On Fri, Jun 9, 2017 at 12:17 PM, Supun Kamburugamuva 
wrote:

> Thanks Bill for bringing up the proposal. Should there be a sentence or
> two describing how Heron compares with Storm?
>
> Regards,
> Supun..
>
> On Thu, Jun 8, 2017 at 1:23 PM, Bill Graham  wrote:
>
>> Dear Apache Incubator Community,
>>
>> We are excited to share our proposal for discussion and feedback
>> for entering Apache Incubation. Heron is a real-time, distributed,
>> fault-tolerant stream processing engine.
>>
>> Our proposal can be found at https://wiki.apache.org/incuba
>> tor/HeronProposal
>>  and is included below.
>>
>>
>> Thank you,
>>
>> Bill Graham on behalf of the Heron developers
>>
>>
>> # Heron Proposal
>>
>> ## Abstract
>> Heron is a real-time, distributed, fault-tolerant stream processing engine
>> initially developed by Twitter.
>>
>> ## Proposal
>>
>> Heron is a real-time stream processing engine built for high performance,
>> ease of manageability, performance predictability and developer
>> productivity[1]. We wish to develop a community around Heron to increase
>> contributions and see Heron thrive in an open forum.
>>
>> ## Background
>>
>> Heron provides the ability for developers to compose directed acyclic
>> graphs (DAGs) of real-time query execution logic (i.e. a topology) and
>> submit the topology to execute on a pluggable job scheduling system (e.g.,
>> Apache Aurora, YARN, Marathon, etc). Users can employ either the native
>> Heron API or the Apache Storm API to develop the topology. Heron supports
>> the Storm API for ease of migration, but beyond that Heron’s architecture
>> differs considerably from Storm’s.
>>
>> Users submit a topology to the scheduler using the Heron client, which
>> uses
>> the Heron binary libraries to deploy all daemons required to run and
>> manage
>> the topology. The topology therefore has no reliance on centrally managed
>> Heron services, only on a generic job scheduling system, which lends
>> itself
>> well to be run on top of Apache Aurora/Mesos or Apache Hadoop/YARN (among
>> others).
>>
>> The scheduler runs each topology as a job consisting of multiple
>> containers. One of the containers runs the topology master, responsible
>> for
>> managing the topology. The remaining containers each runs a stream manager
>> responsible for data routing, a metrics manager that collects and reports
>> various metrics and a number of processes called Heron instances which run
>> the user-defined logic on the stream of tuples. Parallelism is achieved
>> via
>> process-based isolation of Heron instances, which provides predictable
>> performance while simplifying debugging. The containers are allocated and
>> managed by the scheduler framework based on resource availability of nodes
>> in the cluster. The metadata for the topology, such as the physical plan
>> and execution details, are stored in the pluggable Heron State Manager
>> (e.g. Apache ZooKeeper).
>>
>> ## Rationale
>>
>> Heron is a general-purpose, modular and extensible platform that can be
>> leveraged to support common, real-time analytics use cases. There is an
>> increasing demand for open-source, scalable real-time analytics systems.
>> We
>> believe that Heron can be leveraged by other organizations to build
>> streaming applications that can benefit from its robustness, high
>> performance, adaptability to cloud environments and ease of use. Moreover,
>> we hope that open-sourcing Heron will help to further evolve the
>> technology
>> as the project attracts contributors with diverse backgrounds and areas of
>> expertise.
>>
>> We believe the Apache foundation is a great fit as the long-term home for
>> Heron, as it provides an established process for community-driven
>> development and decision making by consensus. This is exactly the model we
>> want for future Heron development.
>>
>> ## Initial Goals
>>
>> * Move the existing codebase, website, documentation, and mailing lists to
>> Apache-hosted infrastructure.
>> * Integrate with the Apache development process.
>> * Ensure all dependencies are compliant with Apache License version 2.0.
>> * Incrementally develop and release per Apache guidelines.
>>
>> ## Current Status
>>
>> Heron is a stable project used in production at Twitter since 2014 and
>> open
>> sourced under the ASL v2 license in 2016. The Heron source code is
>> currently hosted at github.com (https://github.com/twitter/heron), which
>> will seed the Apache git repository.
>>
>> ### Meritocracy
>>
>> By submitting this incubator proposal, we’re expressing our intent to
>> 

Re: [PROPOSAL] Heron

[Supun Kamburugamuva]

Thanks Bill for bringing up the proposal. Should there be a sentence or two
describing how Heron compares with Storm?

Regards,
Supun..

On Thu, Jun 8, 2017 at 1:23 PM, Bill Graham  wrote:

> Dear Apache Incubator Community,
>
> We are excited to share our proposal for discussion and feedback
> for entering Apache Incubation. Heron is a real-time, distributed,
> fault-tolerant stream processing engine.
>
> Our proposal can be found at https://wiki.apache.org/
> incubator/HeronProposal
>  and is included below.
>
>
> Thank you,
>
> Bill Graham on behalf of the Heron developers
>
>
> # Heron Proposal
>
> ## Abstract
> Heron is a real-time, distributed, fault-tolerant stream processing engine
> initially developed by Twitter.
>
> ## Proposal
>
> Heron is a real-time stream processing engine built for high performance,
> ease of manageability, performance predictability and developer
> productivity[1]. We wish to develop a community around Heron to increase
> contributions and see Heron thrive in an open forum.
>
> ## Background
>
> Heron provides the ability for developers to compose directed acyclic
> graphs (DAGs) of real-time query execution logic (i.e. a topology) and
> submit the topology to execute on a pluggable job scheduling system (e.g.,
> Apache Aurora, YARN, Marathon, etc). Users can employ either the native
> Heron API or the Apache Storm API to develop the topology. Heron supports
> the Storm API for ease of migration, but beyond that Heron’s architecture
> differs considerably from Storm’s.
>
> Users submit a topology to the scheduler using the Heron client, which uses
> the Heron binary libraries to deploy all daemons required to run and manage
> the topology. The topology therefore has no reliance on centrally managed
> Heron services, only on a generic job scheduling system, which lends itself
> well to be run on top of Apache Aurora/Mesos or Apache Hadoop/YARN (among
> others).
>
> The scheduler runs each topology as a job consisting of multiple
> containers. One of the containers runs the topology master, responsible for
> managing the topology. The remaining containers each runs a stream manager
> responsible for data routing, a metrics manager that collects and reports
> various metrics and a number of processes called Heron instances which run
> the user-defined logic on the stream of tuples. Parallelism is achieved via
> process-based isolation of Heron instances, which provides predictable
> performance while simplifying debugging. The containers are allocated and
> managed by the scheduler framework based on resource availability of nodes
> in the cluster. The metadata for the topology, such as the physical plan
> and execution details, are stored in the pluggable Heron State Manager
> (e.g. Apache ZooKeeper).
>
> ## Rationale
>
> Heron is a general-purpose, modular and extensible platform that can be
> leveraged to support common, real-time analytics use cases. There is an
> increasing demand for open-source, scalable real-time analytics systems. We
> believe that Heron can be leveraged by other organizations to build
> streaming applications that can benefit from its robustness, high
> performance, adaptability to cloud environments and ease of use. Moreover,
> we hope that open-sourcing Heron will help to further evolve the technology
> as the project attracts contributors with diverse backgrounds and areas of
> expertise.
>
> We believe the Apache foundation is a great fit as the long-term home for
> Heron, as it provides an established process for community-driven
> development and decision making by consensus. This is exactly the model we
> want for future Heron development.
>
> ## Initial Goals
>
> * Move the existing codebase, website, documentation, and mailing lists to
> Apache-hosted infrastructure.
> * Integrate with the Apache development process.
> * Ensure all dependencies are compliant with Apache License version 2.0.
> * Incrementally develop and release per Apache guidelines.
>
> ## Current Status
>
> Heron is a stable project used in production at Twitter since 2014 and open
> sourced under the ASL v2 license in 2016. The Heron source code is
> currently hosted at github.com (https://github.com/twitter/heron), which
> will seed the Apache git repository.
>
> ### Meritocracy
>
> By submitting this incubator proposal, we’re expressing our intent to build
> a diverse developer community around Heron that will conduct itself
> according to The Apache Way and use a meritocratic means of building it's
> committer base. Several companies and universities have already expressed
> interest in and contributed to Heron. Our goal is to grow the Heron
> community by encouraging open communication, contribution and participation
> of all types, and ensuring that contributors are recognized appropriately.
>
> ### Community
>
> Heron is currently being used by Twitter, Google, Machine Zone and
> ndustrial.io and has received significant contributions by 

Re: I would volunteer as mentor for weex

[Raphael Bircher]

Hi all

It's done, thanks!

Regards, Raphael

Am .06.2017, 12:34 Uhr, schrieb John D. Ament :


Raphael,

Great news.  Please feel free to add yourself to the podling via whimsy  
or

podlings.xml.

John

On Fri, Jun 9, 2017 at 6:21 AM Raphael Bircher 
wrote:


Hi all,

After I helped weex with the first release i got asked, if I would
volunteer as Mentor for them. Weex mainly struggles in learning the  
Apache

Way. But I really see willingness to learn it and so I offer my help.

Regards, Raphael

--
My introduction https://youtu.be/Ln4vly5sxYU

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





--
My introduction https://youtu.be/Ln4vly5sxYU

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

Re: I would volunteer as mentor for weex

[John D. Ament]

Raphael,

Great news.  Please feel free to add yourself to the podling via whimsy or
podlings.xml.

John

On Fri, Jun 9, 2017 at 6:21 AM Raphael Bircher 
wrote:

> Hi all,
>
> After I helped weex with the first release i got asked, if I would
> volunteer as Mentor for them. Weex mainly struggles in learning the Apache
> Way. But I really see willingness to learn it and so I offer my help.
>
> Regards, Raphael
>
> --
> My introduction https://youtu.be/Ln4vly5sxYU
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

I would volunteer as mentor for weex

[Raphael Bircher]

Hi all,

After I helped weex with the first release i got asked, if I would  
volunteer as Mentor for them. Weex mainly struggles in learning the Apache  
Way. But I really see willingness to learn it and so I offer my help.


Regards, Raphael

--
My introduction https://youtu.be/Ln4vly5sxYU

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

Re: ASF hosted binaries collecting user data without an explicit opt-in

[Bertrand Delacretaz]

On Fri, Jun 9, 2017 at 7:15 AM, Greg Stein  wrote:
>... Do no evil...

Of course. As long as everybody agrees on the definition of "evil" ;-)

Hence my proposal to briefly document best practices about how to
collect user data in a non-evil way.

Maybe adding a few notes to
https://issues.apache.org/jira/browse/IGNITE-5413 about what infra has
been doing to fix the current issue is sufficient, so that we can
point to that later if similar cases arise.

-Bertrand

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