Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Jochen Wiedmann]

On Thu, Sep 22, 2016 at 7:18 AM, Roman Shaposhnik  wrote:

> Still, the question remain -- for somebody like that, what would be a criteria
> to be added as a committer after the project enters incubation?

Projects decision.



-- 
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Geertjan Wielenga]

Roman Shaposhnik wrote:

> Still, the question remain -- for somebody like that, what would be a
> criteria
> to be added as a committer after the project enters incubation?


Let's stop wasting time -- just provide his name so it can be added to the
list, thanks.

Geertjan

On Thu, Sep 22, 2016 at 7:18 AM, Roman Shaposhnik 
wrote:

> On Wed, Sep 21, 2016 at 1:15 AM, Bertrand Delacretaz
>  wrote:
> > Hi,
> >
> > On Wed, Sep 21, 2016 at 9:34 AM, Mark Struberg
> >  wrote:
> >> ...Please note that during the incubation people need to either show
> that they
> >> are eager to engage with the community...
> >
> > Indeed, but for a well established project like NetBeans I suppose the
> > initial committers will recognize some people as soon as they show up,
> > as contributors to NetBeans before Apache, and suggest electing them
> > quicker than if they were unknown. With such a large project it's
> > probably impossible to create a fully fair initial list of committers,
> > and fixing that shortly after entering incubation is fine.
>
> That's what I was asking about. In particular, the person who was inquiring
> me off-line about this proposal had a non-trivial amount of commits to
> then Sun NetBeans between 2002-2008. He then drifted away from the
> project but would be interested, potentially, re-engaging.
>
> Given the size of the pool of potential candidates like that, I'm not
> saying
> we should block the VOTE until we get the initial committer list just
> right.
>
> Still, the question remain -- for somebody like that, what would be a
> criteria
> to be added as a committer after the project enters incubation?
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Roman Shaposhnik]

On Wed, Sep 21, 2016 at 1:15 AM, Bertrand Delacretaz
 wrote:
> Hi,
>
> On Wed, Sep 21, 2016 at 9:34 AM, Mark Struberg
>  wrote:
>> ...Please note that during the incubation people need to either show that 
>> they
>> are eager to engage with the community...
>
> Indeed, but for a well established project like NetBeans I suppose the
> initial committers will recognize some people as soon as they show up,
> as contributors to NetBeans before Apache, and suggest electing them
> quicker than if they were unknown. With such a large project it's
> probably impossible to create a fully fair initial list of committers,
> and fixing that shortly after entering incubation is fine.

That's what I was asking about. In particular, the person who was inquiring
me off-line about this proposal had a non-trivial amount of commits to
then Sun NetBeans between 2002-2008. He then drifted away from the
project but would be interested, potentially, re-engaging.

Given the size of the pool of potential candidates like that, I'm not saying
we should block the VOTE until we get the initial committer list just right.

Still, the question remain -- for somebody like that, what would be a criteria
to be added as a committer after the project enters incubation?

Thanks,
Roman.

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

Re: [VOTE] Accept Spot into the Apache Incubator

[Todd Lipcon]

+1 (binding)

-Todd

On Tue, Sep 20, 2016 at 11:15 AM, Doug Cutting  wrote:

> Following the discussion thread, I would like to call a vote on
> accepting Spot into the Apache Incubator.
>
> [] +1 Accept Spot into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept Spot into the Apache Incubator because ...
>
> This vote will run for the usual 72 hours.
>
> The proposal is attached, but you can also access it on the wiki:
>https://wiki.apache.org/incubator/SpotProposal
>
> Thanks,
>
> Doug
>
> = SpotProposal =
>
> == Abstract ==
>
> Spot is an open source platform for network telemetry (packet, flow,
> and proxy at the moment) built on an open data model and Apache
> Hadoop.
>
> == Proposal ==
>
> Spot (formerly Open Network Insight, or ONI) is an open source
> solution for network telemetry (packet, flow, and proxy at the moment)
> built on an open data model and Apache Hadoop. It provides ingestion
> and transformation of binary data, scalable machine learning, and
> interactive visualization for identifying threats in network flows and
> DNS packets.
>
> Spot has a pluggable architecture that can accommodate multiple open
> data models. Although cybersecurity/network-intrusion analysis is the
> initial use case for Spot, we are actively encouraging the
> contribution of new models that will enable other adjacent
> applications, such as fraud detection or IT-operational analytics such
> as performance and health monitoring. Because these models are open,
> users maintain control of their own data.
>
> More information on Spot can be found at the existing project website
> at http://open-network-insight.org/.
>
> == Background ==
>
> It almost goes without saying that cybersecurity is an acute and
> paramount concern globally, for organizations of all types and
> sizes. Fortunately, thanks to the availability of massively scalable
> (in the PBs) data infrastructure, security professionals can now make
> authentically data-driven decisions about how they protect their
> assets. For example, records of network traffic, captured as network
> flows, are often stored and analyzed for use in network management,
> and this same information can provide valuable insights into network
> vulnerabilities.
>
> Cybersecurity is just one example, however: There are other examples
> of adjacent use cases, such as user fraud detection or IT-operations
> analytics, that would benefit from the combination of Spot
> functionality and PB-scale data sets for analysis.
>
> == Rationale ==
>
> Although cybersecurity is its initial use case/data model, Spot is
> intended to more generally tackle the dual challenges of facilitating
> the development of big data-driven analytic solutions, while helping
> vendors avoid having to create one/off infrastructure for each use
> case. Spot will eliminate issues related to vendor data models that
> create silos between solutions, and that make it difficult for users
> to consume these innovations from multiple vendors. In summary, Spot
> will accelerate the development of new massively scalable analytic
> applications that give users more flexibility, and more choices.
>
> As an initial effort, we are now seeking to build an ecosystem of
> developers, data scientists, and security professionals to make Spot
> the open, community-driven, cybersecurity platform standard it needs
> to become. By bringing Spot to Apache, we hope to galvanize these
> groups to cooperate in this highly matrixed effort, and to build a
> global, and diverse, Spot community.
>
> == Initial Goals ==
>
> Move the existing codebase, website, documentation, and mailing lists
> to Apache-hosted infrastructure Work with the infrastructure team to
> implement and approve our build and testing workflows in the context
> of the ASF Incremental development and releases per Apache guidelines
>
> == Current Status ==
>
> === Releases ===
>
> Spot has undergone one public release (1.0). This initial release was
> not performed in the typical ASF fashion; we will adopt the ASF source
> release process upon joining the incubator.
>
> === Source ===
>
> Spot’s source, including core platform and associated submodules, is
> currently hosted in several GitHub repositories under the indicated
> licenses:
>
>  * Core (Apache License 2.0)
>  * Oni-ingest (Apache License 2.0)
>  * Oni-ml (Apache License 2.0
>  * Oni-oa (BSD & MIT)
>  * Oni-setup (Apache License 2.0)
>  * Oni-nfdump (BSD)
>  * Oni-lda-c (GNU General Public License version 2)
>
> The repositories will be transitioned to Apache’s git hosting during
> incubation.  Issues related to GPL code will be resolved during
> incubation.
>
>
> === Issue Tracking ===
>
> Spot’s bug and feature tracking is hosted on Github at:
>
>  * https://github.com/Open-Network-Insight/open-network-insight/issues
>
> Issue tracking will be transitioned to Apache’s JIRA instance during
> incubation.
>
> === Code review ===
>
> Spot maintainers currently use “LGTM” 

Re: [discuss] Move podling rosters to LDAP

[Sam Ruby]

cc += gstein

On Wed, Sep 21, 2016 at 9:55 PM, Stian Soiland-Reyes  wrote:
> Did this conclude..? Just in case it didn't, here's my +1 as well to
> make podling membership be in proper LDAP groups; with email
> notifications to private@podling as you mention.

This did not conclude, but you picked an opportune time to resurrect
this thread with Greg joining the infrastructure team.  In fact, I was
planning to restart this thread for exactly that reason; thank you for
doing it.

My assessment previously was that there wasn't enough demand at the
time to overcome inertia.  This change will undoubtedly break things
temporarily, but nothing that can't be fixed quickly.

> (I am lucky enough to have faced the asf-authorization-template a
> couple of times :) )

Join the club. :-)  The current process sucks, doesn't it.  :-)

> Ensuring people.apache.org is updated would also make it easier for
> podlings to refer to a canonical list of who are their members; which
> would work somewhat the same way after graduating.

That's part of the discussion I would like to have.  I'm proposing
that members of the podling can update the group.  Currently only PMC
chairs can modify PMCs.  And furthermore, PMC chairs can modify *any*
PMC, not just the one(s) they chair.

I'd like to change this so that PMC members can modify their own
group.  And I believe that the increased notifications that this tool
will provide will enable proper oversight.

I also believe this to be fully in line with the President's (Ross's)
desire to enable self-service.

But a change of this magnitude to the way that we operate is something
that requires a critical mass of support.  Thanks for lending your
voice to this discussion.

> Letting podling members modify the group themselves is good (as you
> said the worst they can do is add another committer), as long as we'll
> keep the account creation process under the hands of ASF Members (as
> it is now).

ASF members and officers.

By the way, if you ever want to submit an account request, you might
want to try https://whimsy.apache.org/officers/acreq/; it loads much
faster than https://id.apache.org/acreq/; if you like it, spread the
word.

- Sam Ruby

> On 2 September 2016 at 18:52, Sam Ruby  wrote:
>> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament  wrote:
>>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby  wrote:
>>>
 The first stage would be migrating existing lists to LDAP.  This will
 require some small changes to whimsy and the phone book application.
 The whole effort will only take a few hours and be spread over a few
 days elapsed time.

 To prepare, we will need to decide who gets to modify these lists, and
 who gets notified.  I propose that members of podlings be able to modify
 the list, and the private list associated with that podling be notified
 on changes.  Alternate choices would include mentors for the podling, or
 the IPMC.  Given that notification facilitates oversight, I encourage
 this to be pushed down to the podling, but will go with whatever the
 consensus turns out to be.
>>>
>>> My vote would be for mentors to be able to do this.  The podlings don't
>>> know enough yet to manage this on their own.  I would be concerned of
>>> missed process steps if the podling themselves could do it.
>>
>> See Mark's comment, and my response to it.
>>
 The second stage would be to define an interface for adding (and perhaps
 removing) podlings.  This could be limited to the IPMC and the web
 interface could ensure that it is only possible to create entries that
 are present in podlings.xml.

>>>
>>> Could this lead to the eventual removal of podlings.xml ?
>>
>> It could lead to where-ever the IPMC wants to go. :-)
>>
>> My preference is that the canonical definition be in SVN, git, LDAP or
>> some such, and that tools like whimsy remain only a convenient
>> mechanism to update these definitions.
>>
>>> Does any of this have a relationship to projects.apache.org ?
>>
>> At a minimum, both would derive information from a common source.
>>
>> My understanding is that the focus of projects.apache.org is to
>> provide a public-facing and read-only interface to this data.
>>
>> The whimsy roster tool would provide an authenticated read-write
>> interface to this data.  And a non-exclusive one.  Other tools could
>> be written that update that information.
>>
>> - Sam Ruby
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>
>
>
> --
> Stian Soiland-Reyes
> http://orcid.org/-0001-9842-9718
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: 

Re: [discuss] Move podling rosters to LDAP

[Stian Soiland-Reyes]

Did this conclude..? Just in case it didn't, here's my +1 as well to
make podling membership be in proper LDAP groups; with email
notifications to private@podling as you mention.

(I am lucky enough to have faced the asf-authorization-template a
couple of times :) )

Ensuring people.apache.org is updated would also make it easier for
podlings to refer to a canonical list of who are their members; which
would work somewhat the same way after graduating.


Letting podling members modify the group themselves is good (as you
said the worst they can do is add another committer), as long as we'll
keep the account creation process under the hands of ASF Members (as
it is now).


On 2 September 2016 at 18:52, Sam Ruby  wrote:
> On Fri, Sep 2, 2016 at 12:49 PM, John D. Ament  wrote:
>> On Fri, Sep 2, 2016 at 12:42 PM Sam Ruby  wrote:
>>
>>> The first stage would be migrating existing lists to LDAP.  This will
>>> require some small changes to whimsy and the phone book application.
>>> The whole effort will only take a few hours and be spread over a few
>>> days elapsed time.
>>>
>>> To prepare, we will need to decide who gets to modify these lists, and
>>> who gets notified.  I propose that members of podlings be able to modify
>>> the list, and the private list associated with that podling be notified
>>> on changes.  Alternate choices would include mentors for the podling, or
>>> the IPMC.  Given that notification facilitates oversight, I encourage
>>> this to be pushed down to the podling, but will go with whatever the
>>> consensus turns out to be.
>>
>> My vote would be for mentors to be able to do this.  The podlings don't
>> know enough yet to manage this on their own.  I would be concerned of
>> missed process steps if the podling themselves could do it.
>
> See Mark's comment, and my response to it.
>
>>> The second stage would be to define an interface for adding (and perhaps
>>> removing) podlings.  This could be limited to the IPMC and the web
>>> interface could ensure that it is only possible to create entries that
>>> are present in podlings.xml.
>>>
>>
>> Could this lead to the eventual removal of podlings.xml ?
>
> It could lead to where-ever the IPMC wants to go. :-)
>
> My preference is that the canonical definition be in SVN, git, LDAP or
> some such, and that tools like whimsy remain only a convenient
> mechanism to update these definitions.
>
>> Does any of this have a relationship to projects.apache.org ?
>
> At a minimum, both would derive information from a common source.
>
> My understanding is that the focus of projects.apache.org is to
> provide a public-facing and read-only interface to this data.
>
> The whimsy roster tool would provide an authenticated read-write
> interface to this data.  And a non-exclusive one.  Other tools could
> be written that update that information.
>
> - Sam Ruby
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Licensing requirement for binary artifacts without transitive deps

[Donald Szeto]

Hi,

Thanks everyone for the input, especially Stian for taking a thorough look!

On Wed, Sep 21, 2016 at 2:50 PM, Stian Soiland-Reyes 
wrote:

> it's quite a long list.. obviously you should fix your own metadata so
> predictionio does not become one of the "unknown licenses". :)
>

Sure will do.


> I can see a couple of GPL dependencies in there (mysql) which are red
> flags, e.g. mysql-connector-java, stax-api (dual licensed?) but
> otherwise it looks not bad. (quite a long list though! :)
>

With how Spark has evolved recently, we actually have no reason to build
against MySQL connector anymore, so that would be an easy fix.

3) CC No-Commercial
>
> > For documentation in docs/manual/:
> > This work is licensed under a Creative Commons
> > Attribution-NonCommercial-ShareAlike 3.0 Unported License.
> > http://creativecommons.org/licenses/by-nc-sa/3.0/
>
> This is a big no-no I'm afraid.. (Category X).  Apache projects must
> be usable and redistributable also for commercial use.
>

Yes. We have fixed it to be relicensed with APLv2. To my best knowledge,
all external contributions pre-ASF donation required ICLA signatures.


> I also see there are several pictures/binaries which you may need to
> clarify, e.g.
>
> docs/manual/bower_components/jcarousel/examples/_shared/
> img/img3_thumb.jpg:
>JPEG image data, Exif standard: [TIFF image
> data, little-endian, direntries=1, copyright=Marc Wiegelmann],
> baseline, precision 8, 75x75, frames 3
>

Perhaps we can unbundle Bower components from the source tree?

Sorry for the long email - don't be discouraged - PredictionIO looks
> quite good license wise :)
>

We took licensing quite seriously pre-ASF donation. :) Still missed a few
things as you suggested though.

Regards,
Donald

Re: Licensing requirement for binary artifacts without transitive deps

[Stian Soiland-Reyes]

You are right that if you are not redistributing third-party
dependencies yourself (e.g. part of source code or embedded within
ZIP/JAR files) - then you should not be propagating their
NOTICE/LICENSE details.


However you still need to check that the dependencies your code relies
on is acceptable according to
https://www.apache.org/legal/resolved

..that is - any downstream user should be able to take all the JARs
you depend on and assume they are compatible with the Apache license
2.0 (following their attribution requirements).

So for instance if you have dependencies that are licensed as GPL,
LGPL or Amazon Software License, then those would not be compatible.

The exception is if those are OPTIONAL dependencies you would not
normally use - see https://www.apache.org/legal/resolved#optional for
how to deal with those.


As predictionio is using SBT, I had a look at using this plugin

https://github.com/jrudolph/sbt-dependency-graph

which gave a very nice report (eventually):

https://paste.apache.org/nL50


it's quite a long list.. obviously you should fix your own metadata so
predictionio does not become one of the "unknown licenses". :)

You can assume that all the org.apache ones commons-* are also Apache license.

You then need to check each of the 'No license specified' ones like
Jetty and Jettison

Perhaps track this in a wiki page or see if you can tweak the config
for the plugin to map the unknown dependencies.


I can see a couple of GPL dependencies in there (mysql) which are red
flags, e.g. mysql-connector-java, stax-api (dual licensed?) but
otherwise it looks not bad. (quite a long list though! :)


BTW, your LICENSE.txt is looking good. Some comments:

1) 
https://github.com/apache/incubator-predictionio/blob/develop/LICENSE.txt#L214

This reference to Apache Spark can now be removed, as Apache projects
don't need to attribute each-other (we are all ASF). (You can do so by
a regular comment within the file if you like). You should check
Apache Spark's NOTICE if there are any other attributions you should
propagate (in which case they should be in NOTICE rather than LICENSE)

2) No hunt-around required

> The PredictionIO project contains subcomponents with separate copyright 
> notices
> and license terms. Your use of the source code for these subcomponents is
> subject to the terms and conditions of the following licenses.

Users should not be required to hunt around in your source-tree for
other licenses - so all of these needs to be referenced, including for
instance

./docs/manual/bower_components/jcarousel/LICENSE
./docs/manual/bower_components/jquery/MIT-LICENSE.txt
./tools/src/main/resources/assets/bootstrap-3.2.0-dist/  (including
the glyphicons-halflings font)

It's usually enough to just list them in the top level LICENSE.txt
with license name, which files they cover, and refer to the deeper
license files which you generally already seem to have in the source
tree.



3) CC No-Commercial

> For documentation in docs/manual/:
> This work is licensed under a Creative Commons
> Attribution-NonCommercial-ShareAlike 3.0 Unported License.
> http://creativecommons.org/licenses/by-nc-sa/3.0/

This is a big no-no I'm afraid.. (Category X).  Apache projects must
be usable and redistributable also for commercial use.

Was the documentation under docs/ all part of the Software Grant to
ASF, so that it can be relicensed as Apache License? (Check any
outside contributions to them as those would have to sign ICLAs and
agree to the relicensing)

I also see there are several pictures/binaries which you may need to
clarify, e.g.

docs/manual/bower_components/jcarousel/examples/_shared/img/img3_thumb.jpg:
   JPEG image data, Exif standard: [TIFF image
data, little-endian, direntries=1, copyright=Marc Wiegelmann],
baseline, precision 8, 75x75, frames 3


But this should become clear if checking for the license headers of
all the source files.. for instance with Apache Rat or a more crude
grep:

grep -c -r "Licensed to the Apache" .  | grep :0$ | grep -v target


Sorry for the long email - don't be discouraged - PredictionIO looks
quite good license wise :)


On 20 September 2016 at 20:02, Christopher  wrote:
> As I understand things, the licensing information you provide in your
> artifacts should reflect everything contained within that artifact. You do
> not need to provide license/notice information for dependencies which are
> not bundled in your artifact.
>
> On Tue, Sep 20, 2016 at 3:01 PM Donald Szeto  wrote:
>
>> Sorry. I should have mentioned that I am preparing a release for
>> PredictionIO.
>>
>> Regards,
>> Donald
>>
>> On Tuesday, September 20, 2016, Donald Szeto  wrote:
>>
>> > Hi all,
>> >
>> > I am preparing my first Apache release and am wondering if I need to
>> check
>> > licenses of all transitive deps if the release contains:
>> >
>> > - a single source tarball;
>> > - a few binary JAR 

Re: [IP CLEARANCE] JWPlayer SQE (Streaming Query Engine)

[P. Taylor Goetz]

No. They would be removed/skipped on import.

-Taylor

> On Sep 21, 2016, at 2:44 PM, John D. Ament  wrote:
> 
> Are the binaries expected to be imported as well?
> https://github.com/jwplayer/SQE/tree/master/jars
> 
> John
> 
> On Wed, Sep 21, 2016 at 11:41 AM P. Taylor Goetz  wrote:
> 
>> Apache Storm has received a code donation for JWPlayer SQE (Streaming
>> Query Engine):
>> 
>> http://incubator.apache.org/ip-clearance/storm-sqe.html
>> 
>> 
>> The source code can be found at https://github.com/jwplayer/SQE with the
>> following git commit SHA: 68dbbde1117a043a7bded73d89d3d82238715a4b
>> 
>> Please vote to approve this contribution. Lazy consensus applies. If no -1
>> votes are cast within the next 72 hours, the vote passes.
>> 
>> Regards,
>> 
>> -Taylor
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [IP CLEARANCE] JWPlayer SQE (Streaming Query Engine)

[John D. Ament]

Are the binaries expected to be imported as well?
https://github.com/jwplayer/SQE/tree/master/jars

John

On Wed, Sep 21, 2016 at 11:41 AM P. Taylor Goetz  wrote:

> Apache Storm has received a code donation for JWPlayer SQE (Streaming
> Query Engine):
>
> http://incubator.apache.org/ip-clearance/storm-sqe.html
> 
>
> The source code can be found at https://github.com/jwplayer/SQE with the
> following git commit SHA: 68dbbde1117a043a7bded73d89d3d82238715a4b
>
> Please vote to approve this contribution. Lazy consensus applies. If no -1
> votes are cast within the next 72 hours, the vote passes.
>
> Regards,
>
> -Taylor
>

[IP CLEARANCE] JWPlayer SQE (Streaming Query Engine)

[P. Taylor Goetz]

Apache Storm has received a code donation for JWPlayer SQE (Streaming Query 
Engine):

http://incubator.apache.org/ip-clearance/storm-sqe.html 


The source code can be found at https://github.com/jwplayer/SQE with the 
following git commit SHA: 68dbbde1117a043a7bded73d89d3d82238715a4b

Please vote to approve this contribution. Lazy consensus applies. If no -1
votes are cast within the next 72 hours, the vote passes.

Regards,

-Taylor


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Accept Spot into the Apache Incubator

[Gangumalla, Uma]

+1(binding)
 Accept Spot into the Apache Incubator


Regards,
Uma

On 9/20/16, 11:15 AM, "Doug Cutting"  wrote:

>Following the discussion thread, I would like to call a vote on
>accepting Spot into the Apache Incubator.
>
>[] +1 Accept Spot into the Apache Incubator
>[] +0 Abstain.
>[] -1 Do not accept Spot into the Apache Incubator because ...
>
>This vote will run for the usual 72 hours.
>
>The proposal is attached, but you can also access it on the wiki:
>   https://wiki.apache.org/incubator/SpotProposal
>
>Thanks,
>
>Doug
>
>= SpotProposal =
>
>== Abstract ==
>
>Spot is an open source platform for network telemetry (packet, flow,
>and proxy at the moment) built on an open data model and Apache
>Hadoop.
>
>== Proposal ==
>
>Spot (formerly Open Network Insight, or ONI) is an open source
>solution for network telemetry (packet, flow, and proxy at the moment)
>built on an open data model and Apache Hadoop. It provides ingestion
>and transformation of binary data, scalable machine learning, and
>interactive visualization for identifying threats in network flows and
>DNS packets.
>
>Spot has a pluggable architecture that can accommodate multiple open
>data models. Although cybersecurity/network-intrusion analysis is the
>initial use case for Spot, we are actively encouraging the
>contribution of new models that will enable other adjacent
>applications, such as fraud detection or IT-operational analytics such
>as performance and health monitoring. Because these models are open,
>users maintain control of their own data.
>
>More information on Spot can be found at the existing project website
>at http://open-network-insight.org/.
>
>== Background ==
>
>It almost goes without saying that cybersecurity is an acute and
>paramount concern globally, for organizations of all types and
>sizes. Fortunately, thanks to the availability of massively scalable
>(in the PBs) data infrastructure, security professionals can now make
>authentically data-driven decisions about how they protect their
>assets. For example, records of network traffic, captured as network
>flows, are often stored and analyzed for use in network management,
>and this same information can provide valuable insights into network
>vulnerabilities.
>
>Cybersecurity is just one example, however: There are other examples
>of adjacent use cases, such as user fraud detection or IT-operations
>analytics, that would benefit from the combination of Spot
>functionality and PB-scale data sets for analysis.
>
>== Rationale ==
>
>Although cybersecurity is its initial use case/data model, Spot is
>intended to more generally tackle the dual challenges of facilitating
>the development of big data-driven analytic solutions, while helping
>vendors avoid having to create one/off infrastructure for each use
>case. Spot will eliminate issues related to vendor data models that
>create silos between solutions, and that make it difficult for users
>to consume these innovations from multiple vendors. In summary, Spot
>will accelerate the development of new massively scalable analytic
>applications that give users more flexibility, and more choices.
>
>As an initial effort, we are now seeking to build an ecosystem of
>developers, data scientists, and security professionals to make Spot
>the open, community-driven, cybersecurity platform standard it needs
>to become. By bringing Spot to Apache, we hope to galvanize these
>groups to cooperate in this highly matrixed effort, and to build a
>global, and diverse, Spot community.
>
>== Initial Goals ==
>
>Move the existing codebase, website, documentation, and mailing lists
>to Apache-hosted infrastructure Work with the infrastructure team to
>implement and approve our build and testing workflows in the context
>of the ASF Incremental development and releases per Apache guidelines
>
>== Current Status ==
>
>=== Releases ===
>
>Spot has undergone one public release (1.0). This initial release was
>not performed in the typical ASF fashion; we will adopt the ASF source
>release process upon joining the incubator.
>
>=== Source ===
>
>Spot¹s source, including core platform and associated submodules, is
>currently hosted in several GitHub repositories under the indicated
>licenses:
>
> * Core (Apache License 2.0)
> * Oni-ingest (Apache License 2.0)
> * Oni-ml (Apache License 2.0
> * Oni-oa (BSD & MIT)
> * Oni-setup (Apache License 2.0)
> * Oni-nfdump (BSD)
> * Oni-lda-c (GNU General Public License version 2)
>
>The repositories will be transitioned to Apache¹s git hosting during
>incubation.  Issues related to GPL code will be resolved during
>incubation.
>
>
>=== Issue Tracking ===
>
>Spot¹s bug and feature tracking is hosted on Github at:
>
> * https://github.com/Open-Network-Insight/open-network-insight/issues
>
>Issue tracking will be transitioned to Apache¹s JIRA instance during
>incubation.
>
>=== Code review ===
>
>Spot maintainers currently use ³LGTM² (Looks Good to Me) in comments
>on the code review to 

Re: Late is better than never was: NetBeans

[Bertrand Delacretaz]

Hi Jaroslav,

It's great to "see" you here and hear that you're willing to support
NetBeans transition!

On Wed, Sep 21, 2016 at 4:10 PM, Jaroslav Tulach  wrote:
> ...As far as I was told by Geertjan, the incubator review revealed way more
> issues (plugins.netbeans.org, statistics.netbeans.org, etc.) ...

The ASF infrastructure team has rightly requested a more thorough
analysis than usual on the infrastructure requirements for NetBeans,
as that's a much larger podling than usual, with a long history.

This analysis is ongoing, Daniel Gruno from the ASF infra team is
working on it and will report here when complete. It looks like we
don't need to reproduce all the NetBeans infrastructure, and we have
decided to consider plugins.netbeans.org for example as something to
be sorted out during incubation, with ideas expressed in the proposal
discussion thread here [1].

So I think while NetBeans infra requirements are somewhat larger than
usual, we'll find ways to accomodate them, especially given the
willingness of the NetBeans team to adapt to a new home as needed.

-Bertrand

[1] http://s.apache.org/netbeans_proposal

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

Re: [VOTE] Retire Apache Streams to the attic

[apache]

I remain committed to building and sharing open-source software for social web 
data interoperability.  Participating in the incubator process has taught me a 
lot, and I would like the keep the project operating at Apache, but as Ate 
points out the community around this podling has never been healthy and has all 
but disappeared in 2016. 

I would very much welcome anyone interested in this problem to volunteer as a 
mentor or contributor.  With even a few new committed active participants I can 
envision the project graduating to TLP.  Without fresh initiative, it should be 
retired.  Perhaps some of the codebase will be useful elsewhere.

I’ll be submitting a (potentially final) release candidate later today.

Steve Blackmon
sblack...@apache.org
On September 19, 2016 at 10:25:16 AM, Ate Douma (a...@douma.nu) wrote:

On 2016-09-19 17:09, Suneel Marthi wrote:  
> I am sorry to be reading this, but I was at Steve Blackmon's talk last week  
> in Berlin at Flink forward about using Streams + Flink.  
>  
> It was a very interesting talk and I chatted with Steve briefly about the  
> Streams project.  

Good to hear that!  
I wasn't aware Steve was presenting about Streams in Berlin.  

>  
> Is there absolutely no chance of reviving this project or giving the  
> project some more time before calling the attic ?  

Sure there is a chance, but for that the project needs active community  
involvement. Which has been lacking for quite a while now.  
Community building and involvement really is the primary problem for the  
project with only a single active member, which is not sustainable.  
However, if you are willing and able to get actively involved, and rally some  
additional community involvement as well, then I'd be happy to postpone/cancel  
the retirement VOTE for now.  

I suggest to head over to d...@streams.incubator.apache.org, let us know  
what you can and will do for the project, and see how that works out.  

Regards, Ate  

>  
>  
>  
>  
> On Mon, Sep 19, 2016 at 4:58 PM, Ate Douma  wrote:  
>  
>> On 2016-09-19 16:33, Ate Douma wrote:  
>>  
>>> On 2016-09-19 15:44, John D. Ament wrote:  
>>>  
 Ate,  
  
 Please also note the instructions from the incubator's retirement guide.  
  
 http://incubator.apache.org/guides/retirement.html  
  
>>>  
>>> Right.  
>>> Thanks for pointing this out John.  
>>>  
>>> I've never before had to handle a podling retirement and overlooked this  
>>> requires different handling from a TLP retirement.  
>>> And with slightly different consequences, e.g. website will be taken down,  
>>> instead of flagged as being retired.  
>>>  
>>> So, to do this proper, I'll first cancel the vote thread on dev@streams  
>>> and open a new [FINAL][DISCUSS] thread for retirement again, this  
>>> time also pointing to the podling retirement page.  
>>> This way at least everyone on that list will have a proper notice what  
>>> the retirement entails.  
>>> (not that I expect a different outcome, but there is no rush either)  
>>>  
>>  
>> Reading the podling retirement guide a bit more thoroughly, I think I it is  
>> sufficient to restart the [VOTE] thread for retirement on dev@streams  
>> with the  
>> link to the podling retirement guide.  
>>  
>>  
>>  
>>> And after that I'll open the final [VOTE] for retirement here on general@  
>>>  
>>> Ate  
>>>  
>>>  
 John  
  
 On Mon, Sep 19, 2016 at 6:37 AM Ate Douma  wrote:  
  
 FYI, I've started below vote to retire Apache Streams, after I first  
> initiated a  
> [discuss] thread more than a week ago, which resulted in zero feedback.  
>  
> Ate  
> (Streams mentor)  
>  
>  Forwarded Message   
> Subject: [VOTE] Retire Apache Streams to the attic  
> Date: Sun, 18 Sep 2016 23:27:11 +0200  
> From: Ate Douma   
> To: d...@streams.incubator.apache.org  
>  
>  
> As a final follow up on the earlier [discuss] thread, lets formally  
> vote on  
> retiring Apache Streams and move it to the attic.  
>  
> The process is described at http://attic.apache.org/process.html  
>  
> [ ] +1 Move Streams to the Attic  
> [ ] ±0 Proceed according to the majority  
> [ ] -1 Do not move Streams to the Attic, because... [please add  
> justification]  
>  
> Ate  
>  
>  
>  
> -  
> 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  
>>  
>>  
>  

Late is better than never was: NetBeans

[Jaroslav Tulach]

Hi,
my name is Jaroslav Tulach and I am founder and original architect of 
NetBeans. These days I work for OracleLabs on Graal/Truffle project.

I've been observing Geertjan's heroic effort from a distance (as I was busy 
with my day-to-day tasks), but finally I found some time and decided to join 
this mailing list. I love NetBeans and I'd like to contribute to a successful 
transfer of the project to Apache's stewardship. Certainly I don't want  my 
silence to be a reason for not accepting NetBeans - that's something I would 
never forgive myself.

I have always seen NetBeans as a relatively open open source project with good 
build infrastructure, and open development processes - I even gave talks as 
part of NetBeans Certified Engineer Courses about that: http://
wiki.netbeans.org/File:Nbp-contribute_NetBeansCertifiedEngineerCourse.pdf

The one drawback I was aware of was related to producing releases - while the 
code is public (in http://hg.netbeans.org/releases repository), the build 
infrastructure isn't and I even don't know where to find it. Fixing this was 
one important thing I expected from the Apache transition.

As far as I was told by Geertjan, the incubator review revealed way more 
issues (plugins.netbeans.org, statistics.netbeans.org, etc.) and I feel a bit 
embarrassed for not thinking about that sooner. Hopefully none of that is 
critical enough to prevent the transition.

In any case, I am here and I am ready to help removing any roadblocks we may 
find while working on Apache NetBeans.

Jaroslav Tulach
NetBeans Platform Architect
OracleLabs



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

Re: [VOTE] Release SAMOA 0.4.0 (incubating) RC1

[Flavio Junqueira]

+1

- Built from sources and ran tests
- Checked LICENSE, NOTICE, and DISCLAIMER files
- Checked digests and signatures of the sources zip file and pom
- Ran rat through maven

I have some additional feedback:

- `mvn -Pstorm package` didn't build cleanly for me, I got test errors:

#
Tests in error: 
  AlgosTest.testCVPReqVHTWithStorm »  test timed out after 12 milliseconds
  AlgosTest.testVHTWithStorm »  test timed out after 6 milliseconds


Tests run: 4, Failures: 0, Errors: 2, Skipped: 0

[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache SAMOA ... SUCCESS [  5.003 s]
[INFO] samoa-instances  SUCCESS [  2.798 s]
[INFO] samoa-api .. SUCCESS [ 19.174 s]
[INFO] samoa-test . SUCCESS [  4.978 s]
[INFO] samoa-storm  FAILURE [05:25 min]
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 05:58 min
[INFO] Finished at: 2016-09-21T10:12:56+01:00
[INFO] Final Memory: 55M/760M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.18:test (default-test) on 
project samoa-storm: There are test failures.
#

- `mvn apache-rat:check` doesn't run cleanly:

#
[INFO] 55 implicit excludes (use -debug for more details).
[INFO] Exclude: .git/**/*
[INFO] Exclude: **/*.iml
[INFO] Exclude: **/README.md
[INFO] 126 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 13 unknown: 13 generated: 0 
approved: 81 licence.
[INFO] 
[INFO] Reactor Summary:
[INFO] 
[INFO] Apache SAMOA ... FAILURE [  8.998 s]
[INFO] samoa-instances  SKIPPED
[INFO] samoa-api .. SKIPPED
[INFO] samoa-test . SKIPPED
[INFO] samoa-local  SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 19.683 s
[INFO] Finished at: 2016-09-21T10:26:38+01:00
[INFO] Final Memory: 23M/228M
[INFO] 
[ERROR] Failed to execute goal org.apache.rat:apache-rat-plugin:0.10:check 
(default-cli) on project samoa: Too many files with unapproved license: 13 See 
RAT report in: samoa-0.4.0-incubating/target/rat.txt -> [Help 1]
#

> On 20 Sep 2016, at 01:16, Alan Gates  wrote:
> 
> +1.  Checked the LICENSE, NOTICE, and DISCLAIMER files.  Checked the 
> signatures.  Did a build with a clean maven repo.  Checked for binary files.  
> Ran a rat check.
> 
> As a note there are several files that rat complains about.  Based on a quick 
> look I’m not sure it’s possible to add license headers to these files.  If it 
> isn’t it would be nice to put these in the exception list so that rat 
> succeeds.
> 
> Alan.
> 
>> On Sep 19, 2016, at 06:50, Nicolas Kourtellis  wrote:
>> 
>> Hi all,
>> 
>> Our new release has been voted from the Apache SAMOA team and we are
>> opening the vote to the incubator email list for testing.
>> 
>> Please vote on releasing the following release candidate as Apache
>> SAMOA (incubating)
>> version 0.4.0. This release will be the second release for SAMOA in the
>> incubator.
>> 
>> -
>> The commit to be voted on is in the branch "releases/0.4.0-incubating"
>> (commit fc39238dd7d3674c069a8142312da8c1812bc907):
>> https://git1-us-west.apache.org/repos/asf/incubator-samoa/
>> repo?p=incubator-samoa.git;a=commit;h=fc39238dd7d3674c069a8142312da8
>> c1812bc907
>> 
>> Tag v0.4.0-incubating:
>> https://git1-us-west.apache.org/repos/asf/incubator-samoa/
>> repo?p=incubator-samoa.git;a=tag;h=aa5bd941ccbed1aabb46b8119049ac1bb293c3a2
>> 
>> Release artifacts are signed with the following key:
>> *https://people.apache.org/keys/committer/nkourtellis.asc
>> *
>> 
>> The staging repository for this release can be found at:
>> https://repository.apache.org/content/repositories/staging/
>> org/apache/samoa/samoa/0.4.0-incubating/
>> 
>> The developer's version artifacts:
>> 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Bertrand Delacretaz]

Hi,

On Wed, Sep 21, 2016 at 9:34 AM, Mark Struberg
 wrote:
> ...Please note that during the incubation people need to either show that they
> are eager to engage with the community...

Indeed, but for a well established project like NetBeans I suppose the
initial committers will recognize some people as soon as they show up,
as contributors to NetBeans before Apache, and suggest electing them
quicker than if they were unknown. With such a large project it's
probably impossible to create a fully fair initial list of committers,
and fixing that shortly after entering incubation is fine.

The committers and PMC rosters are usually rediscussed before
graduation anyway, so people who signed up but don't become active
during incubation can be omitted, it goes both ways.

> ...Not sure if it would make sense to already split this into PPMC and
> committers for the initial contributors?...

Before voting on incubation you mean? I wouldn't do that - refining
the PMC roster before graduation is fine, but now is too early IMO,
let's see who actually becomes active before making such decisions.

-Bertrand

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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Mark Struberg]

Please note that during the incubation people need to either show that they are 
eager to engage with the community. It's not that the Podling PMC (PPMC) 
randomly invites people just because their name get dropped, but the PPMC holds 
a VOTE based on their merit [1].

Usually all the initial committers of a poddling also become PPMC members.

Not sure if it would make sense to already split this into PPMC and committers 
for the initial contributors?
Did you have any such merit based hierarchy in NetBeans? Or was it depending on 
Oracle who has a saying?



LieGrue,
strub


[1] https://community.apache.org/newcommitter.html





> On Wednesday, 21 September 2016, 7:41, Geertjan Wielenga 
>  wrote:
> > On Wed, Sep 21, 2016 at 6:49 AM, Roman Shaposhnik wrote:
> 
>>  I've recently had an inquiry from a former Sun employee who
>>  used to hack on NetBeans way back when: how was the list
>>  of initial committers determined? Or more importantly, if he
>>  wants to be added to that list up-front would that be OK?
> 
> 
> Very many more will be added once we enter incubation.
> 
> I put the initial list of committers together. The initial list reflect an
> initial list of committers coming from Oracle [though several more will be
> added later] as well as an initial list of committers from companies
> committed to NetBeans primarily because their software, e.g., at Airbus and
> European Space Agency, depends on it.
> 
> A growing list of developers have indicated they'd like to be added too.
> We'll start doing that as indicated in the propopsal -- as soon as the
> proposal has been voted on, accepted, and entered into incubation.
> 
> Thanks,
> 
> Geertjan
> 
> 
> On Wed, Sep 21, 2016 at 6:49 AM, Roman Shaposhnik 
> wrote:
> 
>>  Hi!
>> 
>>  I've recently had an inquiry from a former Sun employee who
>>  used to hack on NetBeans way back when: how was the list
>>  of initial committers determined? Or more importantly, if he
>>  wants to be added to that list up-front would that be OK?
>> 
>>  Thanks,
>>  Roman.
>> 
>>  On Tue, Sep 13, 2016 at 12:40 AM, Geertjan Wielenga
>>   wrote:
>>  > Hello everyone,
>>  >
>>  > Attached to this message is a proposed new project - Apache NetBeans, 
> a
>>  > development environment, tooling platform, and application framework.
>>  >
>>  > The text of the proposal is included below. Additionally, the proposal 
> is
>>  > in draft form on the Wiki, where we will make any required changes:
>>  >
>>  > https://wiki.apache.org/incubator/NetBeansProposal
>>  >
>>  > We look forward to your feedback and input.
>>  >
>>  > Kind regards,
>>  >
>>  > Geertjan
>>  >
>>  > 
>>  >
>>  > = NetBeans Proposal =
>>  >
>>  > == Abstract ==
>>  >
>>  > NetBeans is an open source development environment, tooling platform,
>>  > and application framework, used by 1.5 million individuals each month.
>>  >
>>  > == Proposal ==
>>  >
>>  > Apache NetBeans will continue to focus on the areas it has focused on
>>  > while sponsored by Sun Microsystems and Oracle. It will continue to
>>  > primarily focus on providing tools for the Java ecosystem, while also
>>  > being focused on tools for other ecosystems, languages and
>>  > technologies, such as JavaScript, PHP, and C/C++. It will continue to
>>  > actively support its community by means of mailing lists, tutorials,
>>  > and documentation.
>>  >
>>  > == Background ==
>>  >
>>  > NetBeans started in 1995/96 in Prague, in the Czech Republic, as a
>>  > student project. Sun Microsystems acquired and open sourced it in 2000
>>  > and, with the acquisition of Sun Microsystems by Oracle in 2010,
>>  > became part of Oracle. Throughout its history in Sun Microsystems and
>>  > Oracle, NetBeans has been free and open source and has been leveraged
>>  > by its sponsor as a mechanism for driving the Java ecosystem forward.
>>  >
>>  > == Rationale ==
>>  >
>>  > Although NetBeans is already open source, moving it to a neutral place
>>  > like Apache, with its strong governance model, is expected to help get
>>  > more contributions from various organizations. For example, large
>>  > companies are using NetBeans as an application framework to build
>>  > internal or commercial applications and are much more likely to
>>  > contribute to it once it moves to neutral Apache ground. At the same
>>  > time, though Oracle will relinquish its control over NetBeans,
>>  > individual contributors from Oracle are expected to continue
>>  > contributing to NetBeans after it has been contributed to Apache,
>>  > together with individual contributors from other organizations, as
>>  > well as self-employed individual contributors.
>>  >
>>  > == Initial Goals ==
>>  >
>>  > The initial goals of the NetBeans contribution under the Apache
>>  > umbrella are to establish a new home for an already fully functioning
>>  > project and to open up the governance model so as to 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 21/09/16 à 07:37, Geertjan Wielenga a écrit :
> On Wed, Sep 21, 2016 at 6:49 AM, Roman Shaposhnik wrote:
>
>> I've recently had an inquiry from a former Sun employee who
>> used to hack on NetBeans way back when: how was the list
>> of initial committers determined? Or more importantly, if he
>> wants to be added to that list up-front would that be OK?
>
> Very many more will be added once we enter incubation.
>
> I put the initial list of committers together. The initial list reflect an
> initial list of committers coming from Oracle [though several more will be
> added later] as well as an initial list of committers from companies
> committed to NetBeans primarily because their software, e.g., at Airbus and
> European Space Agency, depends on it.
>
> A growing list of developers have indicated they'd like to be added too.
> We'll start doing that as indicated in the propopsal -- as soon as the
> proposal has been voted on, accepted, and entered into incubation.

That's pretty much what is expected : this is one of the incubation exit
criterium anyway !


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

NOTICE: New mentor for Apache Gearpump [incubating]: Jean-Baptiste Onofré

[Kam Kasravi]

We are pleased to announce that Jean-Baptiste Onofré has agreed to provide
additional mentorship to the Apache Gearpump project [incubating].
Jean-Baptiste is active in many Apache projects including Apache Beam
[incubating] and we're very excited to partake in his future suggestions
and guidance (in addition to our champion Andrew Purtell). Welcome
Jean-Baptiste.

Thanks
The Gearpump Team