[RESULT][VOTE] Release of Apache Mnemonic-0.8.0-incubating [rc1]

[Debojyoti Dutta]

Hi all,

After being opened for over more than 72 hours, the vote for releasing
Apache Mnemonic 0.8.0-incubating passed with 5 binding +1s, 5
non-binding +1s and no 0 or -1.

* Binding votes +1s: *
Uma Gangumalla (umamahesh)
Henry Saputra (hsaputra)
Patrick Hunt (phunt)
Josh Elser (elserj)
Justin Mclean (jmclean)

* Non-binding votes +1s: *
Gang (Gary) Wang (garyw)
Johnu George (johnu)
Chunyong He (chunyong...@gmail.com)
Yanhui Zhao (yanhui.z...@outlook.com)
Wen Tong (pures...@gmail.com)

Project Members Role Info
http://mnemonic.incubator.apache.org/develop/

*Thanks all*
Cheers
Debo Dutta, on behalf of the Apache Mnemonic (incubating) community

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

Re: [VOTE] Heron to enter Apache Incubator

[Bill Graham]

It's grossly inaccurate to refer to Heron as a Storm fork. There are about
132k lines of code in the Heron codebase (plus 166k of codegen), of which
about 7k are to implement the Apache Storm API bindings to the Heron API.

The Rationale section of the proposal discusses the Heron architecture,
which is a complete rewrite with little in common with Storm. The only
overlap is that Heron supports the Storm user API for ease of migration.

The value of having multiple projects to solve a common need is that each
can foster innovation, collaboration and exchange of ideas in different
ways. This is not a new concept to Apache. You can look at the incubator
discussions around Accumulo vs HBase (two implementations of the BigTable
paper) for example, to see how two different approaches to a shared problem
can be a good thing.

thanks,
Bill

On Thu, Jun 22, 2017 at 6:45 PM, Von Gosling  wrote:

> Hi,
>
> I will give +1(Non-binding), but,
>
> I have the similar question about so many streaming framework in the
> apache, how to develop community for themselves.
>
>
>
>
> Best Regards,
> Von Gosling
>
>
>
> 在 2017年6月23日，08:51，Edward Capriolo  写道：
>
> I believe heron and storm should be merged back together. I do not see the
> value of storm and a storm fork in the asf.
>
> On Thursday, June 22, 2017, Bill Graham  wrote:
>
> Thanks Taylor for relaying these sentiments, especially the part about the
> Heron website which is indeed poorly worded (I suspect this could have been
> the result of internal docs being open-sourced). I've opened this pull
> request to update the language regarding Storm:
>
> https://github.com/twitter/heron/pull/1979
>
> On Thu, Jun 22, 2017 at 12:21 PM, P. Taylor Goetz  > wrote:
>
> The Apache Storm PMC had a discussion regarding the Heron proposal. In
>
> the
>
> spirit of openness I wanted to bring some of the sentiments expressed in
> that discussion back to this list. Please note that I am paraphrasing
>
> from
>
> that discussion and attempting to relay opinions of the collective PMC,
>
> not
>
> necessarily that of any individual.
>
> * There is a general disappointment that the Heron community chose not to
> engage with the Storm community and instead chose a separate path.
> * A majority of the PMC supports Heron’s incubation, though some felt it
> would result in unnecessary duplication of effort.
> * A majority of the PMC supports the two projects working closely
> together. A number of PMC members suggested the two projects merge in
>
> some
>
> way.
> * Many PMC members took issue some of the marketing language on the Heron
> website, particularly Heron being billed as “the direct successor to
>
> Apache
>
> Storm” and the prominent “Upgrade from Storm” links.  The main concern
>
> here
>
> was such phrasing has somewhat of a hostile tone and undermines the
>
> desire
>
> for better collaboration, as well as confusing users.
>
> One of my goals as a proposed mentor for Heron and a Storm PMC member is
> to address some of these concerns and encourage collaboration. As I
> mentioned to the Storm PMC on that thread, if there are ongoing concerns
> from either the Storm PMC or the Heron PPMC about me acting as a mentor,
>
> I
>
> would be willing to step down.
>
> +1 (binding)
>
> -Taylor
>
> On Jun 16, 2017, at 4:41 PM, Bill Graham 
> > wrote:
>
>
> Hi,
>
> Based on the discussion on the incubator mailing list[1] I would like
>
> to
>
> call a vote to add Heron to the Apache Incubator.
>
> The full proposal is available below, and is also available on the
>
> Apache
>
> Incubator wiki at:
>   https://wiki.apache.org/incubator/HeronProposal
>
> Please vote:
> [ ] +1, bring Heron into Incubator
> [ ] -1, do not bring Heron into Incubator, because...
>
> The vote will open for 7 days until Friday June 23 at 14:00 PT.
>
> Thank you
>
> 1 -
> https://lists.apache.org/thread.html/fb91f527ef479bb5df45bf2c9d93b7
>
> 786c3fa6cdbfeba3128599df79@%3Cgeneral.incubator.apache.org%3E
>
>
>
>
> = 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

Re: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]

[William Guo]

update text as links, not sure why it was not links in email.

PPMC vote threads:
https://lists.apache.org/thread.html/a298cdc88e7da94e88e3483342a8fc1e647061c9cc4c32aeb12f1ca9@%3Cdev.griffin.apache.org%3E

PPMC vote result threads:
https://lists.apache.org/thread.html/f94c56da6d2b3f777898443a349634e3c76c6c047b205de52cd6643c@%3Cdev.griffin.apache.org%3E



The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating

The tag to be voted upon is 0.1.4-incubating:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.4-incubating


The release hash is f1ad4b7b6390b988f3625df3eba652a7fb59ad68:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=f1ad4b7b6390b988f3625df3eba652a7fb59ad68


The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1002


Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS


KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS


For information about the contents of this release, see:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating/CHANGES.txt


William


From: William Guo 
Sent: Friday, June 23, 2017 10:21:24 AM
To: general@incubator.apache.org; d...@griffin.incubator.apache.org
Subject: [VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]


Dear IPMC,

This is a call for a vote on releasing Apache Griffin 0.1.4-incubating, release 
candidate 2. This is the first release of Griffin.

Apache Griffin is data quality service for modern data system, it defines a 
standard process to define, measure data quality for well-known dimensions. 
With Apache Griffin, users will be able to quickly define their data quality 
requirements and then get the result in near real time in systematical approach.


PPMC vote threads:
https://lists.apache.org/thread.html/a298cdc88e7da94e88e3483342a8fc1e647061c9cc4c32aeb12f1ca9@%3Cdev.griffin.apache.org%3E
PPMC vote result threads:
https://lists.apache.org/thread.html/f94c56da6d2b3f777898443a349634e3c76c6c047b205de52cd6643c@%3Cdev.griffin.apache.org%3E


The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating

The tag to be voted upon is 0.1.4-incubating:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.4-incubating

The release hash is f1ad4b7b6390b988f3625df3eba652a7fb59ad68:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=f1ad4b7b6390b988f3625df3eba652a7fb59ad68

The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1002

Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

For information about the contents of this release, see:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating/CHANGES.txt

Please vote on releasing this package as Apache Griffin 0.1.4-incubating

The vote will be open for 72 hours.

[ ] +1 Release this package as Apache Griffin 0.1.4-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Thanks,
Apache Griffin Team

[VOTE] Release of Apache Griffin 0.1.4-incubating [rc2]

[William Guo]

Dear IPMC,

This is a call for a vote on releasing Apache Griffin 0.1.4-incubating, release 
candidate 2. This is the first release of Griffin.

Apache Griffin is data quality service for modern data system, it defines a 
standard process to define, measure data quality for well-known dimensions. 
With Apache Griffin, users will be able to quickly define their data quality 
requirements and then get the result in near real time in systematical approach.


PPMC vote threads:
https://lists.apache.org/thread.html/a298cdc88e7da94e88e3483342a8fc1e647061c9cc4c32aeb12f1ca9@%3Cdev.griffin.apache.org%3E
PPMC vote result threads:
https://lists.apache.org/thread.html/f94c56da6d2b3f777898443a349634e3c76c6c047b205de52cd6643c@%3Cdev.griffin.apache.org%3E


The source tarball, including signatures, digests, etc. can be found at:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating

The tag to be voted upon is 0.1.4-incubating:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=shortlog;h=refs/tags/0.1.4-incubating

The release hash is f1ad4b7b6390b988f3625df3eba652a7fb59ad68:
https://git-wip-us.apache.org/repos/asf?p=incubator-griffin.git;a=commit;h=f1ad4b7b6390b988f3625df3eba652a7fb59ad68

The Nexus Staging URL:
https://repository.apache.org/content/repositories/orgapachegriffin-1002

Release artifacts are signed with the following key:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

KEYS file available:
https://dist.apache.org/repos/dist/dev/incubator/griffin/KEYS

For information about the contents of this release, see:
https://dist.apache.org/repos/dist/dev/incubator/griffin/0.1.4-incubating/CHANGES.txt

Please vote on releasing this package as Apache Griffin 0.1.4-incubating

The vote will be open for 72 hours.

[ ] +1 Release this package as Apache Griffin 0.1.4-incubating
[ ] +0 no opinion
[ ] -1 Do not release this package because ...

Thanks,
Apache Griffin Team

Re: [VOTE] Heron to enter Apache Incubator

[Von Gosling]

Hi,

I will give +1(Non-binding), but,

I have the similar question about so many streaming framework in the apache, 
how to develop community for themselves. 




Best Regards,
Von Gosling



> 在 2017年6月23日，08:51，Edward Capriolo  写道：
> 
> I believe heron and storm should be merged back together. I do not see the
> value of storm and a storm fork in the asf.
> 
> On Thursday, June 22, 2017, Bill Graham  > wrote:
> 
>> Thanks Taylor for relaying these sentiments, especially the part about the
>> Heron website which is indeed poorly worded (I suspect this could have been
>> the result of internal docs being open-sourced). I've opened this pull
>> request to update the language regarding Storm:
>> 
>> https://github.com/twitter/heron/pull/1979
>> 
>> On Thu, Jun 22, 2017 at 12:21 PM, P. Taylor Goetz > > wrote:
>> 
>>> The Apache Storm PMC had a discussion regarding the Heron proposal. In
>> the
>>> spirit of openness I wanted to bring some of the sentiments expressed in
>>> that discussion back to this list. Please note that I am paraphrasing
>> from
>>> that discussion and attempting to relay opinions of the collective PMC,
>> not
>>> necessarily that of any individual.
>>> 
>>> * There is a general disappointment that the Heron community chose not to
>>> engage with the Storm community and instead chose a separate path.
>>> * A majority of the PMC supports Heron’s incubation, though some felt it
>>> would result in unnecessary duplication of effort.
>>> * A majority of the PMC supports the two projects working closely
>>> together. A number of PMC members suggested the two projects merge in
>> some
>>> way.
>>> * Many PMC members took issue some of the marketing language on the Heron
>>> website, particularly Heron being billed as “the direct successor to
>> Apache
>>> Storm” and the prominent “Upgrade from Storm” links.  The main concern
>> here
>>> was such phrasing has somewhat of a hostile tone and undermines the
>> desire
>>> for better collaboration, as well as confusing users.
>>> 
>>> One of my goals as a proposed mentor for Heron and a Storm PMC member is
>>> to address some of these concerns and encourage collaboration. As I
>>> mentioned to the Storm PMC on that thread, if there are ongoing concerns
>>> from either the Storm PMC or the Heron PPMC about me acting as a mentor,
>> I
>>> would be willing to step down.
>>> 
>>> +1 (binding)
>>> 
>>> -Taylor
>>> 
 On Jun 16, 2017, at 4:41 PM, Bill Graham > > wrote:
 
 Hi,
 
 Based on the discussion on the incubator mailing list[1] I would like
>> to
 call a vote to add Heron to the Apache Incubator.
 
 The full proposal is available below, and is also available on the
>> Apache
 Incubator wiki at:
   https://wiki.apache.org/incubator/HeronProposal
 
 Please vote:
 [ ] +1, bring Heron into Incubator
 [ ] -1, do not bring Heron into Incubator, because...
 
 The vote will open for 7 days until Friday June 23 at 14:00 PT.
 
 Thank you
 
 1 -
 https://lists.apache.org/thread.html/fb91f527ef479bb5df45bf2c9d93b7
>>> 786c3fa6cdbfeba3128599df79@%3Cgeneral.incubator.apache.org%3E
 
 
 
 = 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 

Re: [VOTE] Heron to enter Apache Incubator

[John D. Ament]

All,

I'm requesting that the community holds on closing this vote for a few
extra days to address concerns raised by the Storm community and others.

Please don't interpret this as a -1, but do interpret it as a need for some
extra due dilligence due to code usage from Apache Storm within Heron.

John

On Sun, Jun 18, 2017 at 6:35 AM John D. Ament  wrote:

> +1, however a few things to note about the proposal (and follow up will be
> required when bringing Heron in):
>
> - There is no ASF 2.0 license (missed when putting together the proposal)
> - The IP section doesn't mention anything about a SGA being sent, is your
> intention to not send an SGA?
> - The NOTICE for the repo indicates there is some source code from Yahoo!.
>
> - The contents of https://github.com/twitter/heron/tree/master/third_party 
> seems
> to be mostly binary files, and you'll need to clean that up for your first
> release.
> - Your 3rd party section mentions everything is ASF 2.0, however this
> includes glog and similar tools that include an odd buildchain license that
> is actually GPL, we'll need to get clearance if this is actually compliant
> or not.  Some of the contents in third_party are missing license headers.
>
> John
>
>
> On Fri, Jun 16, 2017 at 4:41 PM Bill Graham  wrote:
>
>> Hi,
>>
>> Based on the discussion on the incubator mailing list[1] I would like to
>> call a vote to add Heron to the Apache Incubator.
>>
>> The full proposal is available below, and is also available on the Apache
>> Incubator wiki at:
>> https://wiki.apache.org/incubator/HeronProposal
>>
>> Please vote:
>>   [ ] +1, bring Heron into Incubator
>>   [ ] -1, do not bring Heron into Incubator, because...
>>
>> The vote will open for 7 days until Friday June 23 at 14:00 PT.
>>
>> Thank you
>>
>> 1 -
>>
>> https://lists.apache.org/thread.html/fb91f527ef479bb5df45bf2c9d93b7786c3fa6cdbfeba3128599df79@%3Cgeneral.incubator.apache.org%3E
>>
>>
>>
>> = 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
>> deve

Re: [VOTE] Heron to enter Apache Incubator

[Edward Capriolo]

I believe heron and storm should be merged back together. I do not see the
value of storm and a storm fork in the asf.

On Thursday, June 22, 2017, Bill Graham  wrote:

> Thanks Taylor for relaying these sentiments, especially the part about the
> Heron website which is indeed poorly worded (I suspect this could have been
> the result of internal docs being open-sourced). I've opened this pull
> request to update the language regarding Storm:
>
> https://github.com/twitter/heron/pull/1979
>
> On Thu, Jun 22, 2017 at 12:21 PM, P. Taylor Goetz  > wrote:
>
> > The Apache Storm PMC had a discussion regarding the Heron proposal. In
> the
> > spirit of openness I wanted to bring some of the sentiments expressed in
> > that discussion back to this list. Please note that I am paraphrasing
> from
> > that discussion and attempting to relay opinions of the collective PMC,
> not
> > necessarily that of any individual.
> >
> > * There is a general disappointment that the Heron community chose not to
> > engage with the Storm community and instead chose a separate path.
> > * A majority of the PMC supports Heron’s incubation, though some felt it
> > would result in unnecessary duplication of effort.
> > * A majority of the PMC supports the two projects working closely
> > together. A number of PMC members suggested the two projects merge in
> some
> > way.
> > * Many PMC members took issue some of the marketing language on the Heron
> > website, particularly Heron being billed as “the direct successor to
> Apache
> > Storm” and the prominent “Upgrade from Storm” links.  The main concern
> here
> > was such phrasing has somewhat of a hostile tone and undermines the
> desire
> > for better collaboration, as well as confusing users.
> >
> > One of my goals as a proposed mentor for Heron and a Storm PMC member is
> > to address some of these concerns and encourage collaboration. As I
> > mentioned to the Storm PMC on that thread, if there are ongoing concerns
> > from either the Storm PMC or the Heron PPMC about me acting as a mentor,
> I
> > would be willing to step down.
> >
> > +1 (binding)
> >
> > -Taylor
> >
> > > On Jun 16, 2017, at 4:41 PM, Bill Graham  > wrote:
> > >
> > > Hi,
> > >
> > > Based on the discussion on the incubator mailing list[1] I would like
> to
> > > call a vote to add Heron to the Apache Incubator.
> > >
> > > The full proposal is available below, and is also available on the
> Apache
> > > Incubator wiki at:
> > >https://wiki.apache.org/incubator/HeronProposal
> > >
> > > Please vote:
> > >  [ ] +1, bring Heron into Incubator
> > >  [ ] -1, do not bring Heron into Incubator, because...
> > >
> > > The vote will open for 7 days until Friday June 23 at 14:00 PT.
> > >
> > > Thank you
> > >
> > > 1 -
> > > https://lists.apache.org/thread.html/fb91f527ef479bb5df45bf2c9d93b7
> > 786c3fa6cdbfeba3128599df79@%3Cgeneral.incubator.apache.org%3E
> > >
> > >
> > >
> > > = 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
> > > pe

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

[Justin Mclean]

Hi,

A late +1 (binding) from me

I checked:
- incubating in names
- signatures good
- LICENSE and NOTICE correct
- all files have ASF headers
- no expected binary files
- can compile from source

Thanks,
Justin

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

Re: [VOTE] Heron to enter Apache Incubator

[Bill Graham]

Thanks Taylor for relaying these sentiments, especially the part about the
Heron website which is indeed poorly worded (I suspect this could have been
the result of internal docs being open-sourced). I've opened this pull
request to update the language regarding Storm:

https://github.com/twitter/heron/pull/1979

On Thu, Jun 22, 2017 at 12:21 PM, P. Taylor Goetz  wrote:

> The Apache Storm PMC had a discussion regarding the Heron proposal. In the
> spirit of openness I wanted to bring some of the sentiments expressed in
> that discussion back to this list. Please note that I am paraphrasing from
> that discussion and attempting to relay opinions of the collective PMC, not
> necessarily that of any individual.
>
> * There is a general disappointment that the Heron community chose not to
> engage with the Storm community and instead chose a separate path.
> * A majority of the PMC supports Heron’s incubation, though some felt it
> would result in unnecessary duplication of effort.
> * A majority of the PMC supports the two projects working closely
> together. A number of PMC members suggested the two projects merge in some
> way.
> * Many PMC members took issue some of the marketing language on the Heron
> website, particularly Heron being billed as “the direct successor to Apache
> Storm” and the prominent “Upgrade from Storm” links.  The main concern here
> was such phrasing has somewhat of a hostile tone and undermines the desire
> for better collaboration, as well as confusing users.
>
> One of my goals as a proposed mentor for Heron and a Storm PMC member is
> to address some of these concerns and encourage collaboration. As I
> mentioned to the Storm PMC on that thread, if there are ongoing concerns
> from either the Storm PMC or the Heron PPMC about me acting as a mentor, I
> would be willing to step down.
>
> +1 (binding)
>
> -Taylor
>
> > On Jun 16, 2017, at 4:41 PM, Bill Graham  wrote:
> >
> > Hi,
> >
> > Based on the discussion on the incubator mailing list[1] I would like to
> > call a vote to add Heron to the Apache Incubator.
> >
> > The full proposal is available below, and is also available on the Apache
> > Incubator wiki at:
> >https://wiki.apache.org/incubator/HeronProposal
> >
> > Please vote:
> >  [ ] +1, bring Heron into Incubator
> >  [ ] -1, do not bring Heron into Incubator, because...
> >
> > The vote will open for 7 days until Friday June 23 at 14:00 PT.
> >
> > Thank you
> >
> > 1 -
> > https://lists.apache.org/thread.html/fb91f527ef479bb5df45bf2c9d93b7
> 786c3fa6cdbfeba3128599df79@%3Cgeneral.incubator.apache.org%3E
> >
> >
> >
> > = 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 

Re: [VOTE] Heron to enter Apache Incubator

[P. Taylor Goetz]

The Apache Storm PMC had a discussion regarding the Heron proposal. In the 
spirit of openness I wanted to bring some of the sentiments expressed in that 
discussion back to this list. Please note that I am paraphrasing from that 
discussion and attempting to relay opinions of the collective PMC, not 
necessarily that of any individual.

* There is a general disappointment that the Heron community chose not to 
engage with the Storm community and instead chose a separate path.
* A majority of the PMC supports Heron’s incubation, though some felt it would 
result in unnecessary duplication of effort.
* A majority of the PMC supports the two projects working closely together. A 
number of PMC members suggested the two projects merge in some way.
* Many PMC members took issue some of the marketing language on the Heron 
website, particularly Heron being billed as “the direct successor to Apache 
Storm” and the prominent “Upgrade from Storm” links.  The main concern here was 
such phrasing has somewhat of a hostile tone and undermines the desire for 
better collaboration, as well as confusing users.

One of my goals as a proposed mentor for Heron and a Storm PMC member is to 
address some of these concerns and encourage collaboration. As I mentioned to 
the Storm PMC on that thread, if there are ongoing concerns from either the 
Storm PMC or the Heron PPMC about me acting as a mentor, I would be willing to 
step down.

+1 (binding)

-Taylor

> On Jun 16, 2017, at 4:41 PM, Bill Graham  wrote:
> 
> Hi,
> 
> Based on the discussion on the incubator mailing list[1] I would like to
> call a vote to add Heron to the Apache Incubator.
> 
> The full proposal is available below, and is also available on the Apache
> Incubator wiki at:
>https://wiki.apache.org/incubator/HeronProposal
> 
> Please vote:
>  [ ] +1, bring Heron into Incubator
>  [ ] -1, do not bring Heron into Incubator, because...
> 
> The vote will open for 7 days until Friday June 23 at 14:00 PT.
> 
> Thank you
> 
> 1 -
> https://lists.apache.org/thread.html/fb91f527ef479bb5df45bf2c9d93b7786c3fa6cdbfeba3128599df79@%3Cgeneral.incubator.apache.org%3E
> 
> 
> 
> = 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 b

Re: [VOTE] Heron to enter Apache Incubator

[Bill Graham]

+1 (non-binding)

On Mon, Jun 19, 2017 at 6:15 AM, Jake Farrell  wrote:

> Thanks John
> Comments inline, will ensure that your points are addressed before the
> first release candidate.
>
> -Jake
>
>
> On Sun, Jun 18, 2017 at 6:35 AM, John D. Ament 
> wrote:
>
>> +1, however a few things to note about the proposal (and follow up will be
>> required when bringing Heron in):
>>
>> - There is no ASF 2.0 license (missed when putting together the proposal)
>>
>
> Will ensure that all licensing checkboxes are addressed before the first
> release candidate goes up for a vote.
>
>
> - The IP section doesn't mention anything about a SGA being sent, is your
>> intention to not send an SGA?
>>
>
> SGA is not required to be filed prior to an incubator acceptance vote, it
> is 100% required before the codebase can be imported by infra, which the
> mentors will ensure does occur. (i've all ready asked the project to get
> this rolling)
>
>
>
>> - The NOTICE for the repo indicates there is some source code from Yahoo!.
>> - The contents of
>> https://github.com/twitter/heron/tree/master/third_party seems
>> to be mostly binary files, and you'll need to clean that up for your first
>> release.
>> - Your 3rd party section mentions everything is ASF 2.0, however this
>> includes glog and similar tools that include an odd buildchain license
>> that
>> is actually GPL, we'll need to get clearance if this is actually compliant
>> or not.  Some of the contents in third_party are missing license headers.
>>
>>
> This is similar to other projects using a local third_party cache
> directory that have come to the Apache Incubator, Cassandra, Mesos and
> Aurora are a couple that jump into mind. We will ensure that this is
> addressed and that no source release contains any of these files.
>
>
>
>> John
>>
>> On Fri, Jun 16, 2017 at 4:41 PM Bill Graham  wrote:
>>
>> > Hi,
>> >
>> > Based on the discussion on the incubator mailing list[1] I would like to
>> > call a vote to add Heron to the Apache Incubator.
>> >
>> > The full proposal is available below, and is also available on the
>> Apache
>> > Incubator wiki at:
>> > https://wiki.apache.org/incubator/HeronProposal
>> >
>> > Please vote:
>> >   [ ] +1, bring Heron into Incubator
>> >   [ ] -1, do not bring Heron into Incubator, because...
>> >
>> > The vote will open for 7 days until Friday June 23 at 14:00 PT.
>> >
>> > Thank you
>> >
>> > 1 -
>> >
>> > https://lists.apache.org/thread.html/fb91f527ef479bb5df45bf2
>> c9d93b7786c3fa6cdbfeba3128599df79@%3Cgeneral.incubator.apache.org%3E
>> >
>> >
>> >
>> > = 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 

[RESULT][VOTE] Apache Fluo Recipes 1.1.0-incubating (rc1)

[Keith Turner]

The vote passed with 3 +1s and no -1s.  Thanks Billie, John, and Josh
for looking at RC1.

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

Re: [DISCUSS] Migrating to the New Incubator Website

[Patrick Hunt]

On Sat, Jun 17, 2017 at 5:35 AM, John D. Ament 
wrote:

> All,
>
> I'd like to start the process to move forward on a new incubator website.
> Based on discussions in the past on list, I wanted to do the following:
>
> - Roll out a new technology stack + repository
> - Leave content in place, while we work later on content enhancements
>
> For right now, I'm planning to leave the existing /projects and
> /ip-clearance in place.  My hope is that we may not need them in the
> future.
>
> The website staging area can be seen here:
> https://incubator.apache.org/ngtest/
> The git repository for the site can be seen here:
> https://git-wip-us.apache.org/repos/asf?p=incubator.git;a=
> shortlog;h=refs/heads/jbake-site
> (with
> github mirror at https://github.com/apache/incubator/tree/jbake-site )
>
> I'd like to get some final feedback on the layout and colors (not the
> content).  I want to start tracking content enhancements in JIRA to help
> come up with a backlog of areas of improvement for our incubator guides.
>
>
I'm very familiar with the old layout, so this may be coloring my feedback.
However I find the new layout to be less usable than previous. In
particular the drop downs lack structure. I think it would be better to
focus on "solutions" e.g. "bootstrapping a new podling" along with assoc
docs, or "graduating a podingling" etc... - basically focus around the
lifecycle of podling rather than a big long list of "guides". Additionally
it's hard to find things with the new layout, I used to use the browser
"search" feature to narrow down to a particular doc. Now I need to click on
each of the drop downs to find the content I'm looking for. Additionally
things like wiki/faq/etc... - can't find them at all.

Patrick


> John
>

Re: [VOTE] Release Apache Juneau 6.3.0-incubating-RC1

[sblackmon]

+1 binding, originally on dev vote thread.

On June 22, 2017 at 9:34:50 AM, John D. Ament (johndam...@apache.org) wrote:

Copying my +1 from dev list. 

John 

On Thu, Jun 22, 2017 at 9:44 AM James Bognar  wrote: 

> The Apache Juneau Incubator PPMC has voted +3 to release Apache Juneau 
> 6.3.0-incubating RC1. This vote carries over +1 binding vote from IPMC 
> members. 
> 
> John D. Ament 
> 
> Incubator PMC members please review and vote on this incubator release. 
> Apache Juneau is... 
> 
> - A toolkit for marshalling POJOs to a wide variety of content types 
> using a common framework. 
> - A REST server API for creating self-documenting REST interfaces using 
> POJOs. 
> - A REST client API for interacting with REST interfaces using POJOs. 
> - A REST microservice API that combines all the features above for 
> creating lightweight standalone REST interfaces that start up in 
> milliseconds. 
> 
> 
> Please see original [VOTE] thread: 
> 
> https://lists.apache.org/thread.html/21d28dd4d82279df6cc53e64561276a4f076783a0199b82ba99e4ecb@%3Cdev.juneau.apache.org%3E
>  
> 
> We've introduced some significant new enhancements to support new use cases 
> in Apache Streams. The full list of changes can be viewed here: 
> http://juneau.incubator.apache.org/site/apidocs/overview-summary.html#6.3.0 
> 
> The binaries are available at: 
> 
> https://dist.apache.org/repos/dist/dev/incubator/juneau/binaries/juneau-6.3.0-incubating-RC1/
>  
> 
> The release candidate to be voted over is available at: 
> 
> https://dist.apache.org/repos/dist/dev/incubator/juneau/source/juneau-6.3.0-incubating-RC1/
>  
> 
> Build the release candidate using: 
> mvn clean install 
> 
> Note: You may get a Rat failure on a generated DEPENDENCIES file. This 
> can be ignored and will be fixed in 6.3.1. 
> 
> The release candidate is signed with a GPG key available at: 
> https://dist.apache.org/repos/dist/release/incubator/juneau/KEYS 
> 
> A staged Maven repository is available for review at: 
> https://repository.apache.org/content/repositories/orgapachejuneau-1012/ 
> 
> Please vote on releasing these packages as: 
> Apache Juneau 6.3.0-incubating 
> 
> This vote will be open until 27-June-2017 1:00pm GMT. 
> [ ] +1 Release this package 
> [ ] 0 I don't feel strongly about it, but don't object 
> [ ] -1 Do not release this package because... 
> 

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

[Billie Rinaldi]

+1 binding (evaluated the release on the PPMC thread)

On 6/19/17 1:49 PM, Keith Turner wrote:

> Dear IPMC,
>
> Please vote for the following release candidate of Apache Fluo Recipes
> 1.1.0-incubating.
>
> PPMC vote threads:
> https://lists.apache.org/thread.html/4c99f51ef5302506f518d69
> 2ff9d65a188027aadc93ba648a75682df@%3Cdev.fluo.apache.org%3E
> https://lists.apache.org/thread.html/4db5c8ed71d070506f26509
> 890d0e1bdba921570f569b236acce94f9@%3Cdev.fluo.apache.org%3E
>
> Staged dist artifacts:
> https://dist.apache.org/repos/dist/dev/incubator/fluo/fluo-r
> ecipes/1.1.0-incubating-rc1/
>
> Staged Maven repository:
> https://repository.apache.org/content/repositories/orgapachefluo-1018
>
> Signing KEYS:
> https://www.apache.org/dist/incubator/fluo/KEYS
> (fingerprint for this release: CF72CA07C8BC86A1C862765F9AACFB56352ACF76)
>
> Git repo:
> https://gitbox.apache.org/repos/asf/incubator-fluo-recipes
> (branch: 1.1.0-incubating-rc1,
> commit: 4769fa9a3a43af030de318c0423a7cae5c5eb4fe)
>
> The vote will be open for at least 72 hours or until necessary number
> of votes are reached.
>
> Thanks,
> The Apache Fluo Team

Re: [VOTE] Release Apache Juneau 6.3.0-incubating-RC1

[John D. Ament]

Copying my +1 from dev list.

John

On Thu, Jun 22, 2017 at 9:44 AM James Bognar  wrote:

> The Apache Juneau Incubator PPMC has voted +3 to release Apache Juneau
> 6.3.0-incubating RC1. This vote carries over +1 binding vote from IPMC
> members.
>
> John D. Ament
>
> Incubator PMC members please review and vote on this incubator release.
> Apache Juneau is...
>
>- A toolkit for marshalling POJOs to a wide variety of content types
>using a common framework.
>- A REST server API for creating self-documenting REST interfaces using
>POJOs.
>- A REST client API for interacting with REST interfaces using POJOs.
>- A REST microservice API that combines all the features above for
>creating lightweight standalone REST interfaces that start up in
>milliseconds.
>
>
> Please see original [VOTE] thread:
>
> https://lists.apache.org/thread.html/21d28dd4d82279df6cc53e64561276a4f076783a0199b82ba99e4ecb@%3Cdev.juneau.apache.org%3E
>
> We've introduced some significant new enhancements to support new use cases
> in Apache Streams. The full list of changes can be viewed here:
> http://juneau.incubator.apache.org/site/apidocs/overview-summary.html#6.3.0
>
> The binaries are available at:
>
> https://dist.apache.org/repos/dist/dev/incubator/juneau/binaries/juneau-6.3.0-incubating-RC1/
>
> The release candidate to be voted over is available at:
>
> https://dist.apache.org/repos/dist/dev/incubator/juneau/source/juneau-6.3.0-incubating-RC1/
>
> Build the release candidate using:
> mvn clean install
>
> Note:  You may get a Rat failure on a generated DEPENDENCIES file.  This
> can be ignored and will be fixed in 6.3.1.
>
> The release candidate is signed with a GPG key available at:
> https://dist.apache.org/repos/dist/release/incubator/juneau/KEYS
>
> A staged Maven repository is available for review at:
> https://repository.apache.org/content/repositories/orgapachejuneau-1012/
>
> Please vote on releasing these packages as:
> Apache Juneau 6.3.0-incubating
>
> This vote will be open until 27-June-2017 1:00pm GMT.
> [ ] +1 Release this package
> [ ] 0 I don't feel strongly about it, but don't object
> [ ] -1 Do not release this package because...
>

[VOTE] Release Apache Juneau 6.3.0-incubating-RC1

[James Bognar]

The Apache Juneau Incubator PPMC has voted +3 to release Apache Juneau
6.3.0-incubating RC1. This vote carries over +1 binding vote from IPMC
members.

John D. Ament

Incubator PMC members please review and vote on this incubator release.
Apache Juneau is...

   - A toolkit for marshalling POJOs to a wide variety of content types
   using a common framework.
   - A REST server API for creating self-documenting REST interfaces using
   POJOs.
   - A REST client API for interacting with REST interfaces using POJOs.
   - A REST microservice API that combines all the features above for
   creating lightweight standalone REST interfaces that start up in
   milliseconds.


Please see original [VOTE] thread:
https://lists.apache.org/thread.html/21d28dd4d82279df6cc53e64561276a4f076783a0199b82ba99e4ecb@%3Cdev.juneau.apache.org%3E

We've introduced some significant new enhancements to support new use cases
in Apache Streams. The full list of changes can be viewed here:
http://juneau.incubator.apache.org/site/apidocs/overview-summary.html#6.3.0

The binaries are available at:
https://dist.apache.org/repos/dist/dev/incubator/juneau/binaries/juneau-6.3.0-incubating-RC1/

The release candidate to be voted over is available at:
https://dist.apache.org/repos/dist/dev/incubator/juneau/source/juneau-6.3.0-incubating-RC1/

Build the release candidate using:
mvn clean install

Note:  You may get a Rat failure on a generated DEPENDENCIES file.  This
can be ignored and will be fixed in 6.3.1.

The release candidate is signed with a GPG key available at:
https://dist.apache.org/repos/dist/release/incubator/juneau/KEYS

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachejuneau-1012/

Please vote on releasing these packages as:
Apache Juneau 6.3.0-incubating

This vote will be open until 27-June-2017 1:00pm GMT.
[ ] +1 Release this package
[ ] 0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

[RESULT] (was Re: [VOTE] Retire the Blur Podling)

[John D. Ament]

With 5 +1 binding and 1 +1 the vote to retire Blur has passed, in addition
to the 3 binding votes on the dev list.  I'll begin the process in coming
days.

John

On Sun, Jun 18, 2017 at 12:30 PM John D. Ament 
wrote:

> All,
>
> This is a call to vote to retire the Blur podling.  Blur has been
> incubating for nearly 5 years and has not grown a community.  It is
> mutually felt that it is time to retire Blur.  There was a successful vote
> on the podling's dev list at [1].  I'm now calling for the Incubator vote
> on the same subject.
>
> [ ] +1 to retire Blur
> [ ] -1 Don't retire Blur because...
>
> Here is my own +1
>
> John
>
> [1]:
> https://lists.apache.org/thread.html/d6e8050a0f94fd9871e69a529d50690c639c9aa0f5d27ef8b52109c1@%3Cblur-dev.incubator.apache.org%3E
>