Re: Throwing my hat in the ring

[Shane Curcuru]

drugg...@primary.net wrote on 5/14/16 8:18 PM:
> Hi, all;
> I've been having a lot of great F2F talks the past few days at the con
> and Marvin has talked me into throwing my hat in the ring to help with
> the incubator project. So, yeah - I'm game to help where I can (and by
> sending this email, it kinda forces me to follow through).

Big +1 for Daniel, great interaction, good ideas, and I love his
Lightning Talks at #ApacheCon.

- Shane

> 
> AIUI, I'm able to be an informal mentor for any podlings of interest
> (hey, there Guacamole!) so I'll just kinda poke around with that for a
> while, but I'll also keep an eye out here for other stuff that comes up.
> 
> I've been soaking up documentation while airport hopping to get a better
> idea of what goes on and what I can do specifically, but unfortunately
> haven't had a chance to read the archives for this list.
> 
> -- 
> Daniel Ruggeri


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

Re: [DISCUSS] PredictionIO incubation proposal

[Simon Chan]

Thanks Roman.

1. Apache Beam looks promising. I agree it can potentially be extremely
useful in, for example, Data Preparator of DASE-architecture engine of
PredictionIO so it can leverage Spark/Flink/Google Dataflow.  Look forward
to hearing more about it.

2. The integration with Apache Zeppelin is definitely a great suggestion.
In fact, Lee Moon Soo, an initial committer of Zeppelin is also listed as
committer in this proposal. Some works have been done previously (
https://docs.prediction.io/datacollection/analytics-zeppelin/) but I
anticipate a tighter collaboration with Apache Zeppelin after PredictionIO
becomes an Apache project.

Regards,
Simon

On Saturday, May 14, 2016, Andrew Purtell  wrote:

> Yikes, apologies for the formatting. It looked fine in Gmail when I sent
> it alas.
>
> I must let the proposers respond to the technical questions but I think I
> can make the general observation that would-be contributors proposing and
> performing work on new and better Apache ecosystem integrations would be
> excellent for the health of the new podling and the ecosystem at large.
>
>
> > On May 14, 2016, at 5:32 PM, Roman Shaposhnik  > wrote:
> >
> > Super excited to see this proposal! This will finally allow us to have
> > an ASF managed
> > backend for next generation data-driven apps that I see emerging quite
> rapidly.
> >
> > The proposal looks great to me (although I'd recommend calling Scala
> > as an implementation
> > language more prominently since it may attract additional developers
> > with affinity to it).
> >
> > I do have two questions about technology:
> >   1. do you think it would be possible to leverage Apache Beam
> (incubating)
> >   for abstracting away dependency on execution frameworks? My
> understanding
> >   is that PredictionIO currently only run on Spark.
> >   2. is there a potential integration with Apache Zeppelin possible?
> >
> > Thanks,
> > Roman.
> >
> >> On Fri, May 13, 2016 at 1:41 PM, Andrew Purtell  > wrote:
> >> Greetings,
> >>
> >> It is my pleasure to
> >>
> >> propose the PredictionIO project for incubation at the Apache Software
> >> Foundation.
> >>
> >> PredictionIO is a
> >> popular
> >> open
> >>
> >> source Machine Learning Server built on top of a state-of-the-art open
> >> source stack, including several Apache technologies, that
> >>
> >> enables developers to manage and deploy production-ready predictive
> >> services for various kinds of machine learning tasks
> >> , with more than 400 production deployments around the world and a
> growing
> >> contributor community.
> >>
> >>
> >> The text of the proposal is included below and is also available at
> >> https://wiki.apache.org/incubator/PredictionIO
> >>
> >> Best regards,
> >> Andrew Purtell
> >>
> >>
> >> = PredictionIO Proposal =
> >>
> >> === Abstract ===
> >> PredictionIO is an open source Machine Learning Server built on top of
> >> state-of-the-art open source stack, that enables developers to manage
> and
> >> deploy production-ready predictive services for various kinds of machine
> >> learning tasks.
> >>
> >> === Proposal ===
> >> The PredictionIO platform consists of the following components:
> >>
> >> * PredictionIO framework - provides the machine learning stack for
> >> building, evaluating and deploying engines with machine learning
> >> algorithms. It uses Apache Spark for processing.
> >>
> >> * Event Server - the machine learning analytics layer for unifying
> events
> >> from multiple platforms. It can use Apache HBase or any JDBC backends
> >> as its data store.
> >>
> >> The PredictionIO community also maintains a
> >>
> >> Template Gallery, a place to
> >> publish and download (free or proprietary) engine templates for
> different
> >> types of machine learning applications, and is a complemental part of
> the
> >> project. At this point we exclude the Template Gallery from the
> proposal,
> >> as it has a separate set of contributors and we’re not familiar with an
> >> Apache approved mechanism to maintain such a gallery.
> >>
> >> You can find the Template Gallery at https://templates.prediction.io/
> >>
> >> === Background ===
> >> PredictionIO was started with a mission to democratize and bring machine
> >> learning to the masses.
> >>
> >> Machine learning has traditionally been a luxury for big companies like
> >> Google, Facebook, and Netflix. There are ML libraries and tools lying
> >> around the internet but the effort of putting them all together as a
> >> production-ready infrastructure is a very resource-intensive task that
> is
> >> remotely reachable by individuals or small businesses.
> >>
> >> PredictionIO is a production-ready, full stack machine learning system
> that
> >> allows organizations of any scale to quickly deploy machine learning
> >> capabilities. It comes with official and community-contributed machine
> >> learning engine templates 

Throwing my hat in the ring

[druggeri]

Hi, all;
I've been having a lot of great F2F talks the past few days at the con 
and Marvin has talked me into throwing my hat in the ring to help with 
the incubator project. So, yeah - I'm game to help where I can (and by 
sending this email, it kinda forces me to follow through).


AIUI, I'm able to be an informal mentor for any podlings of interest 
(hey, there Guacamole!) so I'll just kinda poke around with that for a 
while, but I'll also keep an eye out here for other stuff that comes up.


I've been soaking up documentation while airport hopping to get a better 
idea of what goes on and what I can do specifically, but unfortunately 
haven't had a chance to read the archives for this list.


--
Daniel Ruggeri

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

Re: [DISCUSS] PredictionIO incubation proposal

[Andrew Purtell]

Yikes, apologies for the formatting. It looked fine in Gmail when I sent it 
alas. 

I must let the proposers respond to the technical questions but I think I can 
make the general observation that would-be contributors proposing and 
performing work on new and better Apache ecosystem integrations would be 
excellent for the health of the new podling and the ecosystem at large. 


> On May 14, 2016, at 5:32 PM, Roman Shaposhnik  wrote:
> 
> Super excited to see this proposal! This will finally allow us to have
> an ASF managed
> backend for next generation data-driven apps that I see emerging quite 
> rapidly.
> 
> The proposal looks great to me (although I'd recommend calling Scala
> as an implementation
> language more prominently since it may attract additional developers
> with affinity to it).
> 
> I do have two questions about technology:
>   1. do you think it would be possible to leverage Apache Beam (incubating)
>   for abstracting away dependency on execution frameworks? My 
> understanding
>   is that PredictionIO currently only run on Spark.
>   2. is there a potential integration with Apache Zeppelin possible?
> 
> Thanks,
> Roman.
> 
>> On Fri, May 13, 2016 at 1:41 PM, Andrew Purtell  wrote:
>> Greetings,
>> 
>> It is my pleasure to
>> 
>> propose the PredictionIO project for incubation at the Apache Software
>> Foundation.
>> 
>> PredictionIO is a
>> popular
>> open
>> 
>> source Machine Learning Server built on top of a state-of-the-art open
>> source stack, including several Apache technologies, that
>> 
>> enables developers to manage and deploy production-ready predictive
>> services for various kinds of machine learning tasks
>> , with more than 400 production deployments around the world and a growing
>> contributor community.
>> 
>> 
>> The text of the proposal is included below and is also available at
>> https://wiki.apache.org/incubator/PredictionIO
>> 
>> Best regards,
>> Andrew Purtell
>> 
>> 
>> = PredictionIO Proposal =
>> 
>> === Abstract ===
>> PredictionIO is an open source Machine Learning Server built on top of
>> state-of-the-art open source stack, that enables developers to manage and
>> deploy production-ready predictive services for various kinds of machine
>> learning tasks.
>> 
>> === Proposal ===
>> The PredictionIO platform consists of the following components:
>> 
>> * PredictionIO framework - provides the machine learning stack for
>> building, evaluating and deploying engines with machine learning
>> algorithms. It uses Apache Spark for processing.
>> 
>> * Event Server - the machine learning analytics layer for unifying events
>> from multiple platforms. It can use Apache HBase or any JDBC backends
>> as its data store.
>> 
>> The PredictionIO community also maintains a
>> 
>> Template Gallery, a place to
>> publish and download (free or proprietary) engine templates for different
>> types of machine learning applications, and is a complemental part of the
>> project. At this point we exclude the Template Gallery from the proposal,
>> as it has a separate set of contributors and we’re not familiar with an
>> Apache approved mechanism to maintain such a gallery.
>> 
>> You can find the Template Gallery at https://templates.prediction.io/
>> 
>> === Background ===
>> PredictionIO was started with a mission to democratize and bring machine
>> learning to the masses.
>> 
>> Machine learning has traditionally been a luxury for big companies like
>> Google, Facebook, and Netflix. There are ML libraries and tools lying
>> around the internet but the effort of putting them all together as a
>> production-ready infrastructure is a very resource-intensive task that is
>> remotely reachable by individuals or small businesses.
>> 
>> PredictionIO is a production-ready, full stack machine learning system that
>> allows organizations of any scale to quickly deploy machine learning
>> capabilities. It comes with official and community-contributed machine
>> learning engine templates that are easy to customize.
>> 
>> === Rationale ===
>> As usage and number of contributors to PredictionIO has grown bigger and
>> more diverse, we have sought for an independent framework for the project
>> to keep thriving. We believe the Apache foundation is a great fit. Joining
>> Apache would ensure that tried and true processes and procedures are in
>> place for the growing number of organizations interested in contributing
>> to PredictionIO. PredictionIO is also a good fit for the Apache foundation.
>> PredictionIO was built on top of several Apache projects (HBase, Spark,
>> Hadoop). We are familiar with the Apache process and believe that the
>> democratic and meritocratic nature of the foundation aligns with the
>> project goals.
>> 
>> === Initial Goals ===
>> The initial milestones will be to move the existing codebase to Apache and
>> integrate with the Apache development process. Once this is accomplished,
>> we plan for 

Re: [DISCUSS] PredictionIO incubation proposal

[Roman Shaposhnik]

Super excited to see this proposal! This will finally allow us to have
an ASF managed
backend for next generation data-driven apps that I see emerging quite rapidly.

The proposal looks great to me (although I'd recommend calling Scala
as an implementation
language more prominently since it may attract additional developers
with affinity to it).

I do have two questions about technology:
   1. do you think it would be possible to leverage Apache Beam (incubating)
   for abstracting away dependency on execution frameworks? My understanding
   is that PredictionIO currently only run on Spark.
   2. is there a potential integration with Apache Zeppelin possible?

Thanks,
Roman.

On Fri, May 13, 2016 at 1:41 PM, Andrew Purtell  wrote:
> Greetings,
>
> It is my pleasure to
>
> propose the PredictionIO project for incubation at the Apache Software
> Foundation.
>
> PredictionIO is a
> popular
> open
>
> source Machine Learning Server built on top of a state-of-the-art open
> source stack, including several Apache technologies, that
>
> enables developers to manage and deploy production-ready predictive
> services for various kinds of machine learning tasks
> , with more than 400 production deployments around the world and a growing
> contributor community.
>
>
> The text of the proposal is included below and is also available at
> https://wiki.apache.org/incubator/PredictionIO
>
> Best regards,
> Andrew Purtell
>
>
> = PredictionIO Proposal =
>
> === Abstract ===
> PredictionIO is an open source Machine Learning Server built on top of
> state-of-the-art open source stack, that enables developers to manage and
> deploy production-ready predictive services for various kinds of machine
> learning tasks.
>
> === Proposal ===
> The PredictionIO platform consists of the following components:
>
>  * PredictionIO framework - provides the machine learning stack for
>  building, evaluating and deploying engines with machine learning
>  algorithms. It uses Apache Spark for processing.
>
>  * Event Server - the machine learning analytics layer for unifying events
>  from multiple platforms. It can use Apache HBase or any JDBC backends
>  as its data store.
>
> The PredictionIO community also maintains a
>
> Template Gallery, a place to
> publish and download (free or proprietary) engine templates for different
> types of machine learning applications, and is a complemental part of the
> project. At this point we exclude the Template Gallery from the proposal,
> as it has a separate set of contributors and we’re not familiar with an
> Apache approved mechanism to maintain such a gallery.
>
> You can find the Template Gallery at https://templates.prediction.io/
>
> === Background ===
> PredictionIO was started with a mission to democratize and bring machine
> learning to the masses.
>
> Machine learning has traditionally been a luxury for big companies like
> Google, Facebook, and Netflix. There are ML libraries and tools lying
> around the internet but the effort of putting them all together as a
> production-ready infrastructure is a very resource-intensive task that is
> remotely reachable by individuals or small businesses.
>
> PredictionIO is a production-ready, full stack machine learning system that
> allows organizations of any scale to quickly deploy machine learning
> capabilities. It comes with official and community-contributed machine
> learning engine templates that are easy to customize.
>
> === Rationale ===
> As usage and number of contributors to PredictionIO has grown bigger and
> more diverse, we have sought for an independent framework for the project
> to keep thriving. We believe the Apache foundation is a great fit. Joining
> Apache would ensure that tried and true processes and procedures are in
> place for the growing number of organizations interested in contributing
> to PredictionIO. PredictionIO is also a good fit for the Apache foundation.
> PredictionIO was built on top of several Apache projects (HBase, Spark,
> Hadoop). We are familiar with the Apache process and believe that the
> democratic and meritocratic nature of the foundation aligns with the
> project goals.
>
> === Initial Goals ===
> The initial milestones will be to move the existing codebase to Apache and
> integrate with the Apache development process. Once this is accomplished,
> we plan for incremental development and releases that follow the Apache
> guidelines, as well as growing our developer and user communities.
>
> === Current Status ===
> PredictionIO has undergone nine minor releases and many patches.
> PredictionIO is being used in production by Salesforce.com as well as many
> other organizations and apps. The PredictionIO codebase is currently
> hosted at GitHub, which will form the basis of the Apache git repository.
>
>  Meritocracy 
> We plan to invest in supporting a meritocracy. We will discuss the
> requirements in an open forum. We intend to invite additional developers
> 

Re: Additional mentor steps?

[Roman Shaposhnik]

On Sat, May 14, 2016 at 4:38 PM, John D. Ament  wrote:
> On Sat, May 14, 2016 at 6:29 PM Roman Shaposhnik 
> wrote:
>
>> On Sat, May 14, 2016 at 3:27 PM, Julian Hyde  wrote:
>> > My reaction (being ignorant of the machinery behind phonebook and
>> authorization)
>> > is that adding to asf-authorization-template on podling creation would
>> be ok (since it
>> > is done only once per podling, by a mentor who presumably knows what
>> they are doing)
>> > but adding to asf-authorization-template each time a committer is
>> appointed is probably
>> > too error-prone.
>> >
>> > I might be naive but it seems that the fact that x is a committer to
>> podling y should be
>> > represented in one and only one place and the phonebook ought to drive
>> from that.
>>
>> That's where I'm going with this as well.
>>
>
> Unfortunately, I feel that this opinion isn't shared across the entire ASF
> spectrum, see [1] for instance.  Right now, you are correct, my
> understanding is that we don't want to add podlings to LDAP.  I'm not sure
> the why behind it, and maybe its worth bringing up again.

I'm actually ambivalent about LDAP (although I don't see why not). I'm 100%
with Julian on having a single DB for podling members. SVN auth file just
doesn't feel right (especially for those podlings using Git you know).

Thanks,
Roman.

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

Re: Additional mentor steps?

[John D. Ament]

On Sat, May 14, 2016 at 6:29 PM Roman Shaposhnik 
wrote:

> On Sat, May 14, 2016 at 3:27 PM, Julian Hyde  wrote:
> > My reaction (being ignorant of the machinery behind phonebook and
> authorization)
> > is that adding to asf-authorization-template on podling creation would
> be ok (since it
> > is done only once per podling, by a mentor who presumably knows what
> they are doing)
> > but adding to asf-authorization-template each time a committer is
> appointed is probably
> > too error-prone.
> >
> > I might be naive but it seems that the fact that x is a committer to
> podling y should be
> > represented in one and only one place and the phonebook ought to drive
> from that.
>
> That's where I'm going with this as well.
>

Unfortunately, I feel that this opinion isn't shared across the entire ASF
spectrum, see [1] for instance.  Right now, you are correct, my
understanding is that we don't want to add podlings to LDAP.  I'm not sure
the why behind it, and maybe its worth bringing up again.

John


>
> Thanks,
> Roman.
>
> P.S. And I don't think it is naive, I think it is relational ;-)
>

[1]: https://issues.apache.org/jira/browse/COMDEV-197



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

Re: Additional mentor steps?

[Roman Shaposhnik]

On Sat, May 14, 2016 at 3:27 PM, Julian Hyde  wrote:
> My reaction (being ignorant of the machinery behind phonebook and 
> authorization)
> is that adding to asf-authorization-template on podling creation would be ok 
> (since it
> is done only once per podling, by a mentor who presumably knows what they are 
> doing)
> but adding to asf-authorization-template each time a committer is appointed 
> is probably
> too error-prone.
>
> I might be naive but it seems that the fact that x is a committer to podling 
> y should be
> represented in one and only one place and the phonebook ought to drive from 
> that.

That's where I'm going with this as well.

Thanks,
Roman.

P.S. And I don't think it is naive, I think it is relational ;-)

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

Re: Additional mentor steps?

[Julian Hyde]

My reaction (being ignorant of the machinery behind phonebook and 
authorization) is that adding to asf-authorization-template on podling creation 
would be ok (since it is done only once per podling, by a mentor who presumably 
knows what they are doing) but adding to asf-authorization-template each time a 
committer is appointed is probably too error-prone.

I might be naive but it seems that the fact that x is a committer to podling y 
should be represented in one and only one place and the phonebook ought to 
drive from that.

Julian

> On May 14, 2016, at 1:01 PM, Roman Shaposhnik  wrote:
> 
> To answer back into the original thread (based on the question about
> Phonebook last week):
> 
> On Thu, Apr 28, 2016 at 6:51 PM, John D. Ament  wrote:
>> All,
>> 
>> Due to some changes in recent times around the ASF, I think I've identified
>> a new setup step for podlings.
>> 
>> I'd like to recommend adding to the asf-authorization-template as a setup
>> step to display the newly created podling in phonebook (
>> home.apache.org/phonebook.html) and that whenever a new committer is added
>> that this authorization template be updated.
>> 
>> Any objections? Questions or concerns?
> 
> I like the idea. My only concern is that what needs to be updated today
> is esoteric (puppet file?) and confusing (svn?). Is there any chance we
> can make it less so?
> 
> As I understand the key issue here is that we don't want to create LDAP
> entries for podling committers, correct?
> 
> Roman.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: Additional mentor steps?

[Roman Shaposhnik]

To answer back into the original thread (based on the question about
Phonebook last week):

On Thu, Apr 28, 2016 at 6:51 PM, John D. Ament  wrote:
> All,
>
> Due to some changes in recent times around the ASF, I think I've identified
> a new setup step for podlings.
>
> I'd like to recommend adding to the asf-authorization-template as a setup
> step to display the newly created podling in phonebook (
> home.apache.org/phonebook.html) and that whenever a new committer is added
> that this authorization template be updated.
>
> Any objections? Questions or concerns?

I like the idea. My only concern is that what needs to be updated today
is esoteric (puppet file?) and confusing (svn?). Is there any chance we
can make it less so?

As I understand the key issue here is that we don't want to create LDAP
entries for podling committers, correct?

Roman.

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

Re: [VOTE] Accept Fluo into the Apache Incubator

[Suneel Marthi]

+1
Sent from my iPhone

> On May 14, 2016, at 11:21 AM, Ted Dunning  wrote:
> 
> +1
> 
> 
> 
> On Sat, May 14, 2016 at 10:09 AM, James Taylor 
> wrote:
> 
>> +1 (binding)
>> 
>> On Sat, May 14, 2016 at 9:31 AM, Roman Shaposhnik 
>> wrote:
>> 
>>> On Fri, May 13, 2016 at 11:22 AM, Billie Rinaldi 
>>> wrote:
 Since discussion has died down, I would like to call a VOTE on
>> accepting
 Fluo into the Apache Incubator.
 
 Proposal: http://wiki.apache.org/incubator/FluoProposal
 
 [ ] +1 Accept Fluo into the Apache Incubator
 [ ] +0 Abstain.
 [ ] -1 Do not accept Fluo into the Apache Incubator because…
>>> 
>>> +1 (binding)
>>> 
>>> Thanks,
>>> Roman.
>>> 
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 

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

Re: [VOTE] Accept Fluo into the Apache Incubator

[Ted Dunning]

+1



On Sat, May 14, 2016 at 10:09 AM, James Taylor 
wrote:

> +1 (binding)
>
> On Sat, May 14, 2016 at 9:31 AM, Roman Shaposhnik 
> wrote:
>
> > On Fri, May 13, 2016 at 11:22 AM, Billie Rinaldi 
> > wrote:
> > > Since discussion has died down, I would like to call a VOTE on
> accepting
> > > Fluo into the Apache Incubator.
> > >
> > > Proposal: http://wiki.apache.org/incubator/FluoProposal
> > >
> > > [ ] +1 Accept Fluo into the Apache Incubator
> > > [ ] +0 Abstain.
> > > [ ] -1 Do not accept Fluo into the Apache Incubator because…
> >
> > +1 (binding)
> >
> > Thanks,
> > Roman.
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Accept Fluo into the Apache Incubator

[James Taylor]

+1 (binding)

On Sat, May 14, 2016 at 9:31 AM, Roman Shaposhnik 
wrote:

> On Fri, May 13, 2016 at 11:22 AM, Billie Rinaldi 
> wrote:
> > Since discussion has died down, I would like to call a VOTE on accepting
> > Fluo into the Apache Incubator.
> >
> > Proposal: http://wiki.apache.org/incubator/FluoProposal
> >
> > [ ] +1 Accept Fluo into the Apache Incubator
> > [ ] +0 Abstain.
> > [ ] -1 Do not accept Fluo into the Apache Incubator because…
>
> +1 (binding)
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept Fluo into the Apache Incubator

[Roman Shaposhnik]

On Fri, May 13, 2016 at 11:22 AM, Billie Rinaldi  wrote:
> Since discussion has died down, I would like to call a VOTE on accepting
> Fluo into the Apache Incubator.
>
> Proposal: http://wiki.apache.org/incubator/FluoProposal
>
> [ ] +1 Accept Fluo into the Apache Incubator
> [ ] +0 Abstain.
> [ ] -1 Do not accept Fluo into the Apache Incubator because…

+1 (binding)

Thanks,
Roman.

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