Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Geertjan Wielenga]

Hi all,

Indeed, I now have greater clarity on the initial contributors list thanks
to meeting John Ament this afternoon.

The initial contributors list is somehow a magic list. Anyone on the list
will, once the proposal has been voted on and accepted, automatically be
contributors to the Apache NetBeans project. Anyone not on the list will
need to be voted in by the initial contributors, which is a process that
could be fast, but is still a process and can be avoided by inclusion in
the initial contributors list. Everyone on the initial contributors list is
automatically part of the PMC. Anyone added to the contributors list after
the proposal has been accepted needs to be voted into the contributors list
and can also be invited by the PMC members to join the PMC. At the end of
the incubation period, the contributors list will be examined and those who
haven't contributed can be approached to ask whether they'd rather not be
removed from the list. Anyone on the list when the project leaves
incubation gets write access to the project for the rest of their life.

I may have misinterpreted something, though I hope the above covers the
whole of it. I hope someone will clarify on the points I may have
misunderstood.

If the above is accurate, we do need to work on the initial contributors
list prior to voting on the proposal, quite aside from the infra assessment.

The following categories of people need to be approached to invite onto the
initial contributors list:

1. Everyone who has contributed to NetBeans over the past 6 months or so
who are currently not one of the 26 Oracle employees currently on the
initial contributors list. These are all Oracle employees, as well as at
least one other, who is already on the initial contributors list --
Emmanuel Hugonnet from Red Hat who has contributed the WildFly plugin to
the NetBeans repository and continues to develop it there. I am not sure
how many additional initial contributors this will result in, I estimate
potentially around 20.

2. Everyone who has created or provided a NetBeans plugin over the past 6
months or so. Not only will these people need to sign an individual
contributors agreement, but also a software grant agreement, to enable
their code to be contributed to Apache NetBeans. Not everyone who makes
functionality available will be relevant to contributing their code to
NetBeans, in some cases they may simply want to continue making plugins
available rather than direct source code contributions. Some of the plugin
authors are from organizations, e.g., the TypeScript plugin is provided by
developers at a company called Everlaw, who may or may not want to make
their code directly available to Apache NetBeans. Other plugins provide
useful bits of functionality, e.g., several of the plugins by Benno
Markiewicz fall into this category, which should simply be part of Apache
NetBeans rather than being provided as plugins. Caoyuan Deng is another
example, working on the Scala plugin, as well as the developers who have
worked on the Python plugin. I estimate that the number of initial
contributors from this category number at least about 20.

3. Ex-employees from Sun and Oracle who have worked on NetBeans in the past
and may want to get involved again. Here I'm thinking of people such as
Milos Kleint who worked on, for example, the Apache Maven integration, as
well as several others, including Radim Kubacki (developer of
NBAndroid.org) and Jesse Glick, as well as Ralph Ruijs, plus several more.
In this category, I estimate about 10 to 20 people might be applicable.

4. Random other people, e.g., Wade Chandler, who has been participating in
this thread, and has been working recently on Groovy enhancements for
NetBeans IDE. This is not a separate plugin and there are other cases where
there are potential individual contributors who don't fall into the above
categories.

5. Anyone else who I may have skipped above, e.g., the person Roman was
referring to earlier, and anyone who volunteers after we send a few e-mails
to the various NetBeans mailing lists.

6. A final point about "intent" and "interest" in John Ament's mail above.
There are two types of these -- those that are definitely going to be
contributing because their software depends on NetBeans, e.g., Microchip's
MPLAB X is an IDE on top of NetBeans IDE, and the related developers have a
very strong interest in committing themselves to Apache NetBeans. I propose
we do keep this category of people in the initial contributors list, which
is why I put them there initially -- they are different to someone who may
have a vague idea about one day maybe contributing. This may seem a strange
category and the argument could be made that they should only be added once
they actually contribute during incubation. For this category, however,
since their interest is so strong and visceral because their business
literally depends on NetBeans, we keep them in the initial contributors
list and, in the unlikely event 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[John D. Ament]

I spoke with Geertjan this afternoon.  We both happened to be at the same
popular java conference in San Francisco.  I did give him some advice on
the current initial contributors list.  Basically two notes:

- Add new members based on merit, not because prior to joining they are
interested.  The way he explained it to me, many of the initial committers
are interested in giving back to Netbeans.  They aren't able to due to the
licensing model from Oracle but are willing to under Apache.  This doesn't
mean they will or will not contribute, but there is an intent.  It may be
better to add them to the project as they begin contributing.

- Ensure that everyone who has contributed to Netbeans in the past is aware
and eligible to be a contributor.  There may be past employees who want to
still give back.  Or even present employees who are now working on other
projects.  They shouldn't necessarily be excluded from the list because
they don't currently work on Netbeans right now.

I do see some issues for the project if they miss people from the list.
Voting in committers can be seen as a pain, especially if it is a
potentially large list (I'm fairly certain that the initial committers list
here is the largest of any project so far at Apache).

I also want to make sure that the infra assessment is done before voting
starts, just to make sure we're all in alignment on what is being expected.

John

On Thu, Sep 22, 2016 at 6:28 AM Stian Soiland-Reyes 
wrote:

> I'm very convinced :-)  I think the Netbeans proposal is ready for a
> [VOTE]!
>
>
>
> On 22 September 2016 at 13:57, Wade Chandler 
> wrote:
> >
> >> On Sep 22, 2016, at 08:27, Shane Curcuru  wrote:
> >>
> >> Jochen Wiedmann wrote on 9/22/16 1:43 AM:
> >>> On Thu, Sep 22, 2016 at 7:18 AM, Roman Shaposhnik <
> ro...@shaposhnik.org> 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.
> >>
> >> Exactly so.  This would be a podling just like every other podling, and
> >> the IPMC would expect the PPMC to start operating like an Apache
> >> project.  That is, when new people come to the podling and contribute
> >> work, and help the work of the podling, that after a time the PPMC will
> >> discuss them, then vote them in as new committers.
> >>
> >> Past merit (i.e. past contributions) is a great help to a new
> >> contributor to a project, both because it's easier to get started, and
> >> because the community already has a feel for how they act and can help.
> >> But it in no way IMO directly leads to current merit.  Old contributors
> >> normally would be voted in as committers only once they actually start
> >> doing new work on the project.
> >
> > Perhaps we need to clarify what you mean by “old contributor” … Do you
> mean those currently contributing to the imported project, those who have
> contributed at some time in the past, but not in X days/months, or anyone
> not on the initial committer list? If the latter, then why would this be
> true for a current OSS project coming to ASF? If this is exactly the case,
> then more emphasis is put on the initial committer list IMO, and that seems
> an unnecessary distraction, and an artificial limit, but if it must be that
> way it must, and if not, then great, but please clarify.
> >
> > I ask this because I recently contributed some things for Groovy
> support, and intend to work quite a bit on those features. I have
> contributed quite a bit to the form (UI editor), J2EE, and Java SE modules
> in the past. I don’t want to suddenly be hindered just because the project
> moves to the ASF where I have to “start over”; I have invested quite a
> number of years into NetBeans and it’s community.
> >
> >> On Sep 22, 2016, at 07:00, Stian Soiland-Reyes 
> wrote:
> >>
> >> Agree - but the initial committer list is also an opportunity to show
> >> you really mean open development, and that it's not just business as
> >> usual with Friends & Family on the list.
> >>
> >
> > Understood, but the impression still has to be on the community all the
> rules of merit apply regardless of perception. I have faith Gj and many I
> know on that initial list will make sure anyone who has made solid code
> contributions to NB, who also want to contribute in the ASF, will be fast
> tracked per prior NB community decisions. We are operating off this
> assumption now; community and Oracle included per my understanding.
> >
> >> One of the freedoms a project gains from moving to ASF is (somewhat)
> >> relief from institutional political considerations.  A new intern at a
> >> company would no longer just be given carte blance write access
> >> without first engaging with the whole community and earning merit
> >> through contributions. Of course each community decides how high or
> >> low the bar should 

Re: [VOTE] Retire Apache Streams to the attic

[Ate Douma]

On 2016-09-21 18:28, apache wrote:

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.


Hi Steve,

Although the retirement for Apache Streams hasn't been formally decided, as
there hasn't been any further signal for support or initiative, it does look
like we'll have to draw that conclusion soon.

You really tried your best in making Apache Streams a success, and with the
openness and focus fitting for the Apache Software Foundation.
That it didn't work out as anticipated and hoped for is of course
disappointing, but sometimes that's just the way things goes.

I definitely hope you will stick to it and at the ASF, contributing to and
joining other projects because you clearly demonstrated to be an fine Apache
committer. And not just because you are a nice and really smart guy, but also
as a great advocate of the Apache Way, at ApacheCons and other places!


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


I'll take a look and review the release candidate over the weekend, which if OK
and when receiving +3 from the IPMC, indeed might become a final incubating 
release for Apache Stream.


I'll follow up later on the VOTE thread for the release candidate on
d...@streams.incubator.apache.org

Kind regards, Ate



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 
>

Fwd: [VOTE] Apache BatchEE 0.4-incubating

[Romain Manni-Bucau]

Hi general@!

FYI the BatchEE incubation project is votiing on batchee 0.4-incubating

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory


-- Forwarded message --
From: Romain Manni-Bucau 
Date: 2016-09-22 18:16 GMT+02:00
Subject: [VOTE] Apache BatchEE 0.4-incubating
To: "d...@batchee.incubator.apache.org" 


Hi guys,

we discussed it several time so here it is: the vote for batchee N+1

Here is the release note: https://issues.apache.org/jira/secure/ReleaseNote.
jspa?projectId=12314924=12334147

Staging repo: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/ (yes numbers are funny sometimes ;))

Source zip: https://repository.apache.org/content/repositories/
orgapachebatchee-1004/org/apache/batchee/batchee/0.4-incubating/batchee-0.4-
incubating-source-release.zip

Tag: https://github.com/rmannibucau/incubator-batchee/
tree/batchee-0.4-incubating

My gpg key is in tomee KEYS file (https://dist.apache.org/
repos/dist/release/tomee/KEYS) - didn't find the batchee one ATM

Please VOTE
[+1] yep
[+0] don’t care
[-1] no cause [...]

The VOTE is open for 72h

Thanks,
Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Wordpress Blog
 | Github  |
LinkedIn  | Tomitriber
 | JavaEE Factory

Re: [discuss] Move podling rosters to LDAP

[Stian Soiland-Reyes]

Does means podlings will also need to define both a $podling and
$podling-pmc group?

Many podlings don't have a clear distinction - at least not in listings.
Perhaps they should..

On 22 Sep 2016 3:17 a.m., "Sam Ruby"  wrote:

> 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
> >>
> >> 

Re: [VOTE] Accept Spot into the Apache Incubator

[Debo Dutta (dedutta)]

+1

Sent from my iPhone

> On Sep 22, 2016, at 12:57 AM, Tom White  wrote:
> 
> +1
> 
> Tom
> 
>> On Tue, Sep 20, 2016 at 7:15 PM, 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 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Stian Soiland-Reyes]

I'm very convinced :-)  I think the Netbeans proposal is ready for a [VOTE]!



On 22 September 2016 at 13:57, Wade Chandler  wrote:
>
>> On Sep 22, 2016, at 08:27, Shane Curcuru  wrote:
>>
>> Jochen Wiedmann wrote on 9/22/16 1:43 AM:
>>> 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.
>>
>> Exactly so.  This would be a podling just like every other podling, and
>> the IPMC would expect the PPMC to start operating like an Apache
>> project.  That is, when new people come to the podling and contribute
>> work, and help the work of the podling, that after a time the PPMC will
>> discuss them, then vote them in as new committers.
>>
>> Past merit (i.e. past contributions) is a great help to a new
>> contributor to a project, both because it's easier to get started, and
>> because the community already has a feel for how they act and can help.
>> But it in no way IMO directly leads to current merit.  Old contributors
>> normally would be voted in as committers only once they actually start
>> doing new work on the project.
>
> Perhaps we need to clarify what you mean by “old contributor” … Do you mean 
> those currently contributing to the imported project, those who have 
> contributed at some time in the past, but not in X days/months, or anyone not 
> on the initial committer list? If the latter, then why would this be true for 
> a current OSS project coming to ASF? If this is exactly the case, then more 
> emphasis is put on the initial committer list IMO, and that seems an 
> unnecessary distraction, and an artificial limit, but if it must be that way 
> it must, and if not, then great, but please clarify.
>
> I ask this because I recently contributed some things for Groovy support, and 
> intend to work quite a bit on those features. I have contributed quite a bit 
> to the form (UI editor), J2EE, and Java SE modules in the past. I don’t want 
> to suddenly be hindered just because the project moves to the ASF where I 
> have to “start over”; I have invested quite a number of years into NetBeans 
> and it’s community.
>
>> On Sep 22, 2016, at 07:00, Stian Soiland-Reyes  wrote:
>>
>> Agree - but the initial committer list is also an opportunity to show
>> you really mean open development, and that it's not just business as
>> usual with Friends & Family on the list.
>>
>
> Understood, but the impression still has to be on the community all the rules 
> of merit apply regardless of perception. I have faith Gj and many I know on 
> that initial list will make sure anyone who has made solid code contributions 
> to NB, who also want to contribute in the ASF, will be fast tracked per prior 
> NB community decisions. We are operating off this assumption now; community 
> and Oracle included per my understanding.
>
>> One of the freedoms a project gains from moving to ASF is (somewhat)
>> relief from institutional political considerations.  A new intern at a
>> company would no longer just be given carte blance write access
>> without first engaging with the whole community and earning merit
>> through contributions. Of course each community decides how high or
>> low the bar should be to earn committership - but the bar should be
>> the same for anyone.
>>
> I 100% agree with this. I think it is definitely that the rules have to apply 
> to everyone equally including employees of a company including the donor. I 
> don’t imagine someone who falls outside categories of merit in the current NB 
> process now should suddenly be committers at ASF. Committers should be 
> committers. Those who were well on their way to earn committer status should 
> be considered, and it should be rare they are not promoted. Those not 
> committing code or submitting patches now, should start from the premise they 
> have to earn committer rights, and the project should enforce that as a 
> minimum; merit isn’t about free trophies or we’d all have doctorates or be in 
> the NFL or NBA :-D
>
>>
>> I found for several podlings that people (myself included) who were
>> perhaps dormant "contributors" before the Incubator 'woke up' after
>> being added as an equal peer on the initial list. The beginning of a
>> podling; while sometimes struggling a bit with bootstrapping, is also
>> a chance for a project to review many of its practices and to build
>> common ownership - reduce the "us and them" feeling.
>>
>
> Sure; IMHO a sane committer of old should be a sane committer of new; if they 
> want to be involved. My understanding in the current NB processes that is 
> true now. Certainly in an OSS world people come and work as they can, and 
> sometimes they can do more than other times. Sometimes they necessarily have 
> to become dormant; 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Bertrand Delacretaz]

Hi,

On Thu, Sep 22, 2016 at 2:57 PM, Wade Chandler  wrote:
> ...I recently contributed some things for Groovy support, and intend to work 
> quite a bit on those features...

Anyone who works "quite a bit" on something that adds value to the
project and interacts in a constructive way on the project's lists
should be elected a committer rather sooner than later, in my book.

How soon is the project's choice, there are no strong Apache rules
about this and there are different styles, but as a NetBeans mentor I
will push for short waiting times as I've had good results that way in
the past.

-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

[Wade Chandler]

> On Sep 22, 2016, at 08:27, Shane Curcuru  wrote:
> 
> Jochen Wiedmann wrote on 9/22/16 1:43 AM:
>> 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.
> 
> Exactly so.  This would be a podling just like every other podling, and
> the IPMC would expect the PPMC to start operating like an Apache
> project.  That is, when new people come to the podling and contribute
> work, and help the work of the podling, that after a time the PPMC will
> discuss them, then vote them in as new committers.
> 
> Past merit (i.e. past contributions) is a great help to a new
> contributor to a project, both because it's easier to get started, and
> because the community already has a feel for how they act and can help.
> But it in no way IMO directly leads to current merit.  Old contributors
> normally would be voted in as committers only once they actually start
> doing new work on the project.

Perhaps we need to clarify what you mean by “old contributor” … Do you mean 
those currently contributing to the imported project, those who have 
contributed at some time in the past, but not in X days/months, or anyone not 
on the initial committer list? If the latter, then why would this be true for a 
current OSS project coming to ASF? If this is exactly the case, then more 
emphasis is put on the initial committer list IMO, and that seems an 
unnecessary distraction, and an artificial limit, but if it must be that way it 
must, and if not, then great, but please clarify.

I ask this because I recently contributed some things for Groovy support, and 
intend to work quite a bit on those features. I have contributed quite a bit to 
the form (UI editor), J2EE, and Java SE modules in the past. I don’t want to 
suddenly be hindered just because the project moves to the ASF where I have to 
“start over”; I have invested quite a number of years into NetBeans and it’s 
community.

> On Sep 22, 2016, at 07:00, Stian Soiland-Reyes  wrote:
> 
> Agree - but the initial committer list is also an opportunity to show
> you really mean open development, and that it's not just business as
> usual with Friends & Family on the list.
> 

Understood, but the impression still has to be on the community all the rules 
of merit apply regardless of perception. I have faith Gj and many I know on 
that initial list will make sure anyone who has made solid code contributions 
to NB, who also want to contribute in the ASF, will be fast tracked per prior 
NB community decisions. We are operating off this assumption now; community and 
Oracle included per my understanding.

> One of the freedoms a project gains from moving to ASF is (somewhat)
> relief from institutional political considerations.  A new intern at a
> company would no longer just be given carte blance write access
> without first engaging with the whole community and earning merit
> through contributions. Of course each community decides how high or
> low the bar should be to earn committership - but the bar should be
> the same for anyone.
> 
I 100% agree with this. I think it is definitely that the rules have to apply 
to everyone equally including employees of a company including the donor. I 
don’t imagine someone who falls outside categories of merit in the current NB 
process now should suddenly be committers at ASF. Committers should be 
committers. Those who were well on their way to earn committer status should be 
considered, and it should be rare they are not promoted. Those not committing 
code or submitting patches now, should start from the premise they have to earn 
committer rights, and the project should enforce that as a minimum; merit isn’t 
about free trophies or we’d all have doctorates or be in the NFL or NBA :-D

> 
> I found for several podlings that people (myself included) who were
> perhaps dormant "contributors" before the Incubator 'woke up' after
> being added as an equal peer on the initial list. The beginning of a
> podling; while sometimes struggling a bit with bootstrapping, is also
> a chance for a project to review many of its practices and to build
> common ownership - reduce the "us and them" feeling.
> 

Sure; IMHO a sane committer of old should be a sane committer of new; if they 
want to be involved. My understanding in the current NB processes that is true 
now. Certainly in an OSS world people come and work as they can, and sometimes 
they can do more than other times. Sometimes they necessarily have to become 
dormant; children, jobs, friends, life… In the NB community we understand this 
and respect it; a work life balance.

> I think Netbeans has the balance somewhat right - but I would hope
> there would be more engagement on their existing lists to more openly
> invite anyone who wants to 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Shane Curcuru]

Jochen Wiedmann wrote on 9/22/16 1:43 AM:
> 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.

Exactly so.  This would be a podling just like every other podling, and
the IPMC would expect the PPMC to start operating like an Apache
project.  That is, when new people come to the podling and contribute
work, and help the work of the podling, that after a time the PPMC will
discuss them, then vote them in as new committers.

Past merit (i.e. past contributions) is a great help to a new
contributor to a project, both because it's easier to get started, and
because the community already has a feel for how they act and can help.
But it in no way IMO directly leads to current merit.  Old contributors
normally would be voted in as committers only once they actually start
doing new work on the project.

- Shane


-
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

[Bertrand Delacretaz]

On Thu, Sep 22, 2016 at 1:40 PM, Geertjan Wielenga
 wrote:
>...there hasn't even been a vote on the proposal at this stage. :-)

Correct ;-)

FWIW I've seen an internal draft of Daniel Gruno's infrastructure cost
analysis so that's progressing nicely, we should have public results
soon and can then move forward.

-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

[Geertjan Wielenga]

On Thu, Sep 22, 2016 at 1:00 PM, Stian Soiland-Reyes wrote:
>
> I think Netbeans has the balance somewhat right - but I would hope
> there would be more engagement on their existing lists to more openly
> invite anyone who wants to join; or at least make it clear that the
> whole of the community (read: mailing list) gets to influence project
> decisions.


Yes, once we are in incubation we will do that. We are not in incubation
yet and I feel we are wasting time with this discussion, I haven't seen
anyone actually caring about whether they're on the initial committers list
or not. We as a community don't care about whatever status that brings, to
be honest. I'd prefer to stop talking about the initial committers list, to
be honest at this point, there hasn't even been a vote on the proposal at
this stage. :-)

On Thu, Sep 22, 2016 at 1:00 PM, Stian Soiland-Reyes 
wrote:

> Agree - but the initial committer list is also an opportunity to show
> you really mean open development, and that it's not just business as
> usual with Friends & Family on the list.
>
> One of the freedoms a project gains from moving to ASF is (somewhat)
> relief from institutional political considerations.  A new intern at a
> company would no longer just be given carte blance write access
> without first engaging with the whole community and earning merit
> through contributions. Of course each community decides how high or
> low the bar should be to earn committership - but the bar should be
> the same for anyone.
>
>
> I found for several podlings that people (myself included) who were
> perhaps dormant "contributors" before the Incubator 'woke up' after
> being added as an equal peer on the initial list. The beginning of a
> podling; while sometimes struggling a bit with bootstrapping, is also
> a chance for a project to review many of its practices and to build
> common ownership - reduce the "us and them" feeling.
>
> I think Netbeans has the balance somewhat right - but I would hope
> there would be more engagement on their existing lists to more openly
> invite anyone who wants to join; or at least make it clear that the
> whole of the community (read: mailing list) gets to influence project
> decisions.
>
> On 22 September 2016 at 09:48, Bertrand Delacretaz
>  wrote:
> > Hi Wade,
> >
> > On Wed, Sep 21, 2016 at 11:38 PM, Wade Chandler
> >  wrote:
> >> ..I can say as a long time contributor who is not on the initial list, I
> >> understand, think it is fine, and agree that being added once we get
> into
> >> the actual incubation phase makes sense...
> >
> > Thanks!
> >
> > As someone who has mentored several projects here in the last ten
> > years or so I think although people sometimes see a lot of value in
> > being on the initial committers list they should not, IMO.
> >
> > What very often happens during incubation is some people who were on
> > this list almost never contribute to the project, and other expected
> > or unexpected people show up, do great things and get elected as a
> > result.
> >
> > Also, as mentor I will recommend reviewing the list of committers and
> > PMC members shortly before graduation, to give the opportunity to
> > people who didn't actually become active to gracefully retire - if the
> > project governance works it's easy to come back later by becoming
> > active, and the project benefits from having a roster that reflects
> > the reality of active contributors.
> >
> > So in summary people shouldn't put too much value on the initial list
> > of committers, it's just that - an initial list, a kind of draft that
> > will evolve during incubation, and probably evolve a lot for a large
> > project such as NetBeans.
> >
> >> ...I am able to contribute as much as I can at this stage anyways...
> >
> > Indeed, and that stays true once incubation starts. Even though an
> > Apache PMC ultimately makes all the project decisions, they are
> > expected to listen to their community. The "community" section at
> > https://community.apache.org/apache-way/apache-project-
> maturity-model.html
> > expresses that.
> >
> >> ...getting into building a thorough list before hand will
> >> certainly take time away from higher priority items at this stage...
> >
> > Yes, that's why the NetBeans mentors pushed to avoid adding people to
> > the list of initial committers before the incubation vote starts, as
> > for a popular project that's a lot of work with no real value as
> > mentioned above.
> >
> > Thanks for your understanding and for your contributions so far!
> >
> > -Bertrand, with my NetBeans mentor hat on
> >
> > -
> > 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
>
> 

Re: [VOTE] Accept Spot into the Apache Incubator

[Stack]

+1 (binding)
St.Ack

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] Apache NetBeans Incubator Proposal

[Stian Soiland-Reyes]

Agree - but the initial committer list is also an opportunity to show
you really mean open development, and that it's not just business as
usual with Friends & Family on the list.

One of the freedoms a project gains from moving to ASF is (somewhat)
relief from institutional political considerations.  A new intern at a
company would no longer just be given carte blance write access
without first engaging with the whole community and earning merit
through contributions. Of course each community decides how high or
low the bar should be to earn committership - but the bar should be
the same for anyone.


I found for several podlings that people (myself included) who were
perhaps dormant "contributors" before the Incubator 'woke up' after
being added as an equal peer on the initial list. The beginning of a
podling; while sometimes struggling a bit with bootstrapping, is also
a chance for a project to review many of its practices and to build
common ownership - reduce the "us and them" feeling.

I think Netbeans has the balance somewhat right - but I would hope
there would be more engagement on their existing lists to more openly
invite anyone who wants to join; or at least make it clear that the
whole of the community (read: mailing list) gets to influence project
decisions.

On 22 September 2016 at 09:48, Bertrand Delacretaz
 wrote:
> Hi Wade,
>
> On Wed, Sep 21, 2016 at 11:38 PM, Wade Chandler
>  wrote:
>> ..I can say as a long time contributor who is not on the initial list, I
>> understand, think it is fine, and agree that being added once we get into
>> the actual incubation phase makes sense...
>
> Thanks!
>
> As someone who has mentored several projects here in the last ten
> years or so I think although people sometimes see a lot of value in
> being on the initial committers list they should not, IMO.
>
> What very often happens during incubation is some people who were on
> this list almost never contribute to the project, and other expected
> or unexpected people show up, do great things and get elected as a
> result.
>
> Also, as mentor I will recommend reviewing the list of committers and
> PMC members shortly before graduation, to give the opportunity to
> people who didn't actually become active to gracefully retire - if the
> project governance works it's easy to come back later by becoming
> active, and the project benefits from having a roster that reflects
> the reality of active contributors.
>
> So in summary people shouldn't put too much value on the initial list
> of committers, it's just that - an initial list, a kind of draft that
> will evolve during incubation, and probably evolve a lot for a large
> project such as NetBeans.
>
>> ...I am able to contribute as much as I can at this stage anyways...
>
> Indeed, and that stays true once incubation starts. Even though an
> Apache PMC ultimately makes all the project decisions, they are
> expected to listen to their community. The "community" section at
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> expresses that.
>
>> ...getting into building a thorough list before hand will
>> certainly take time away from higher priority items at this stage...
>
> Yes, that's why the NetBeans mentors pushed to avoid adding people to
> the list of initial committers before the incubation vote starts, as
> for a popular project that's a lot of work with no real value as
> mentioned above.
>
> Thanks for your understanding and for your contributions so far!
>
> -Bertrand, with my NetBeans mentor hat on
>
> -
> 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: [VOTE] Accept Spot into the Apache Incubator

[Zheng, Kai]

+1 (non-binding). Thanks!

Regards,
Kai

-Original Message-
From: Tom White [mailto:tom.e.wh...@gmail.com] 
Sent: Thursday, September 22, 2016 3:57 PM
To: general@incubator.apache.org
Subject: Re: [VOTE] Accept Spot into the Apache Incubator

+1

Tom

On Tue, Sep 20, 2016 at 7:15 PM, 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 ===
>
> 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Bertrand Delacretaz]

Hi Wade,

On Wed, Sep 21, 2016 at 11:38 PM, Wade Chandler
 wrote:
> ..I can say as a long time contributor who is not on the initial list, I
> understand, think it is fine, and agree that being added once we get into
> the actual incubation phase makes sense...

Thanks!

As someone who has mentored several projects here in the last ten
years or so I think although people sometimes see a lot of value in
being on the initial committers list they should not, IMO.

What very often happens during incubation is some people who were on
this list almost never contribute to the project, and other expected
or unexpected people show up, do great things and get elected as a
result.

Also, as mentor I will recommend reviewing the list of committers and
PMC members shortly before graduation, to give the opportunity to
people who didn't actually become active to gracefully retire - if the
project governance works it's easy to come back later by becoming
active, and the project benefits from having a roster that reflects
the reality of active contributors.

So in summary people shouldn't put too much value on the initial list
of committers, it's just that - an initial list, a kind of draft that
will evolve during incubation, and probably evolve a lot for a large
project such as NetBeans.

> ...I am able to contribute as much as I can at this stage anyways...

Indeed, and that stays true once incubation starts. Even though an
Apache PMC ultimately makes all the project decisions, they are
expected to listen to their community. The "community" section at
https://community.apache.org/apache-way/apache-project-maturity-model.html
expresses that.

> ...getting into building a thorough list before hand will
> certainly take time away from higher priority items at this stage...

Yes, that's why the NetBeans mentors pushed to avoid adding people to
the list of initial committers before the incubation vote starts, as
for a popular project that's a lot of work with no real value as
mentioned above.

Thanks for your understanding and for your contributions so far!

-Bertrand, with my NetBeans mentor hat on

-
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

[Tom White]

+1

Tom

On Tue, Sep 20, 2016 at 7:15 PM, 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 

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Wade Chandler]

On Sep 21, 2016 4: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.
>
>

I can say as a long time contributor who is not on the initial list, I
understand, think it is fine, and agree that being added once we get into
the actual incubation phase makes sense. It seems moot until then as you
can see I am able to contribute as much as I can at this stage anyways. I
think that is the direction people need if they do not already know or
understand it as getting into building a thorough list before hand will
certainly take time away from higher priority items at this stage.

Thanks

Wade