Re: DRAFT report February 2016 -- please review

[Marvin Humphrey]

> 
> Blur
>
> Blur is a search platform capable of searching massive amounts of data
> in a cloud computing environment.
>
> Blur has been incubating since 2012-07-24.
>
> Three most important issues to address in the move towards graduation:
>
>   1. Greater community involvement.
>   2. Produce releases.
>   3.
>
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> aware of?
>
>  - No
>
> How has the community developed since the last report?
>
>  - Subscriptions: user@ - 56[+1]; dev@ - 72[+2]
>  - The community involvement has not really changed over the past few
>months.
>
> How has the project developed since the last report?
>
>  - The software has a few additional features, and bug fixes.
>
> Date of last release:
>
>   2014-07-29
>
> When were the last committers or PMC members elected?
>
>   2014-07-28
>
> Signed-off-by:
>
>   [ ](blur) Doug Cutting
>   [X](blur) Patrick Hunt
>   [ ](blur) Tim Williams
>
> Shepherd/Mentor notes:

Blur has now been incubating for a while: 3 1/2 years.  The Incubator has a
lot of podlings right now and at some point there's going to be an "up or out"
push.  What is holding back Blur from graduation and how can progress be
expedited?

> 
> Climate Model Diagnostic Analyzer
>
> CMDA provides web services for multi-aspect physics-based and phenomenon-
> oriented climate model performance evaluation and diagnosis through the
> comprehensive and synergistic use of multiple observational data, reanalysis
> data, and model outputs.
>
> Climate Model Diagnostic Analyzer has been incubating since 2015-05-08.
>
> Three most important issues to address in the move towards graduation:
>
>   1.
>   2.
>   3.
>
> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> aware of?
>
>
>
> How has the community developed since the last report?
>
>
>
> How has the project developed since the last report?
>
>   1. We have developed a few more analysis tools to support multi-variable
>  diagnostic analyses. The new tools are random forest importance ranking
>  and empirical orthogonal function.
>   2. We have enhanced the web browser capability of our analysis tools. We
>  make a callable URL for each service call with user specified
>  configuration to run the service. With the URL, one can easily share
>  their analysis configuration and result with their colleagues.
>   3. The provenance support system is further enhanced by adding a function
>  to generate a knowledge graph with customizable options for the
>  entities involved and connections between the entities.
>   4. We developed a docker image for the analysis system and deployed in our
>  development server.
>
> Date of last release:
>
>
>
> When were the last committers or PMC members elected?
>
>
>
> Signed-off-by:
>
>   [ ](climatemodeldiagnosticanalyzer) James W. Carman
>   [ ](climatemodeldiagnosticanalyzer) Chris Mattmann
>   [ ](climatemodeldiagnosticanalyzer) Michael James Joyce
>   [ ](climatemodeldiagnosticanalyzer) Kim Whitehall
>   [ ](climatemodeldiagnosticanalyzer) Gregory D. Reddin
>
> Shepherd/Mentor notes:
>

It's appreciated that CMDA took the time to produce detailed information on
project development.  However, that alone does not make a report -- in fact,
it's not the most important part of a report.  The ASF is technology-neutral
by design and while it nice to see activity described, the Board and the IPMC
don't interfere at the technical level and thus have limited use for such
info.  How the *community* is developing is more germane.

This report is incomplete and has no Mentor signoff, so I expect to remove it
and ask CMDA to resubmit next month.

> 
> Concerted

> Shepherd/Mentor notes:
>
>   Chris Nauroth (cnauroth):
>
> Once again, I'll echo concerns about lack of activity and potential
> long-term viability of the project.
>
>   Julian Hyde (jhyde):
>
> I share Chris's concerns. The project claim that activity is happening
> in private; if so, it would be hugely beneficial to make that activity
> public. Having said that, filing a report on time and appointing a
> committer is activity, and that is appreciated.

Thanks, Chris and Julian!  That's great constructive criticism and we all hope
that Concerted is able to make use of it.

> Signed-off-by:
>
>   [ ](slider) Arun C Murthy
>   [ ](slider) Devaraj Das
>   [ ](slider) Jean-Baptiste Onofré
>   [ ](slider) Mahadev Konar

Slider's report needs Mentor signoff.

> 
> SystemML

> Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> aware of?
>
>   NONE. We have resolved our blocking infrastructure issues related to
>   project JIRA.

Great to hear!

> 
> Unomi

> Date of last release:
>
>   Unomi 1.0.0-incubating (take 2) has been called to vote, but the vote
>   didn't passed due to:
>
>   * the src distribution included binaries
>   

Re: [VOTE] Apache SystemML 0.9.0-incubating (RC3)

[Reynold Xin]

+1

(some issues as pointed out above, but we can fix those in the next release)


On Sat, Feb 6, 2016 at 11:29 AM, Luciano Resende 
wrote:

> Let me reiterate my +1 (binding) vote here...
>
> Anyone else willing to review the release ?
>
> On Mon, Feb 1, 2016 at 2:57 PM, Luciano Resende 
> wrote:
>
> > Please vote to approve the release of the following candidate as Apache
> > SystemML version 0.9.0!
> >
> > The PPMC vote thread:
> >
> >
> https://www.mail-archive.com/dev@systemml.incubator.apache.org/msg00267.html
> >
> > And the result:
> >
> >
> https://www.mail-archive.com/dev@systemml.incubator.apache.org/msg00279.html
> >
> > The tag to be voted on is v0.9.0-rc3
> > (49528085a9b2ea0babade040db821c8158a57ab5)
> >
> >
> >
> https://github.com/apache/incubator-systemml/tree/49528085a9b2ea0babade040db821c8158a57ab5
> >
> > The release files, including signatures, digests, etc. can be found at:
> >
> >
> https://repository.apache.org/content/repositories/orgapachesystemml-1003/
> >
> > The distribution and rat report is also available at:
> >
> > http://people.apache.org/~lresende/systemml/0.9.0-rc3/
> >
> > The vote is open for at least 72 hours and passes if a majority of at
> > least 3 +1 PMC votes are cast.
> >
> > [ ] +1 Release this package as Apache SystemML 0.9.0
> > [ ] -1 Do not release this package because ...
> >
> >
> >
> > --
> > Luciano Resende
> > http://people.apache.org/~lresende
> > http://twitter.com/lresende1975
> > http://lresende.blogspot.com/
> >
> >
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
>

RE: [DISCUSSION] How to deal with runtime dependencies

[Markus Geiß]

Thanks for the feedback.

The branch develop reflects the code we are talking about, and can
be found here:

https://github.com/apache/incubator-fineract/tree/develop

Best,

Markus

.::YAGNI likes a DRY KISS::.

> Date: Wed, 10 Feb 2016 19:07:28 -0800
> Subject: Re: FW: [DISCUSSION] How to deal with runtime dependencies
> From: jacq...@apache.org
> To: general@incubator.apache.org
> 
> I've used this as reference previously:
> 
> http://www.apache.org/legal/resolved.html#prohibited
> 
> Specifically this sentence:
> 
> "...For example, using a GPL'ed tool during the build is OK."
> 
> That would suggest that using GPL tools for build and test should be okay.
> 
> I'll let others address the distribution of optional components question in
> great detail. My sense is this is primarily focused on how "optional" the
> undistributable component is.
> 
> On Wed, Feb 10, 2016 at 12:56 AM, Markus Geiß  wrote:
> 
> > Hey all,
> >
> > We've started a thread at our dev list and forgot to send it to the
> > general incubator list too.
> > Any opinion is appreciated, you can find the original message below.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
> >
> > > From: markus.ge...@live.de
> > > To: d...@fineract.incubator.apache.org
> > > Subject: [DISCUSSION] How to deal with runtime dependencies
> > > Date: Mon, 8 Feb 2016 14:12:04 +0100
> > >
> > > Hey all,
> > >
> > > hope this finds you well.
> > >
> > > I thought instead of discussing this on top of pull request, because it
> > is more
> > > than just the JDBC driver, it is the right time to create a new thread.
> > >
> > > We are currently using MySQL's Connector/J and Hibernate's EntityManager
> > at
> > > runtime as the JDBC driver and JPA implementation. Our source code is not
> > > depending on both.
> > >
> > > It would create a huge effort to replace both for test and production
> > environments.
> > >
> > > The questions is:
> > >
> > > Would it be compliant with the license policies if we omit them for our
> > source
> > > release, but keeping them for our own integration tests.
> > >
> > > If somebody is creating a deployable distribution, the expectation is
> > that whomever
> > > is creating the distribution can decide what he wants to use.
> > >
> > > Best,
> > >
> > > Markus
> > >
> > > .::YAGNI likes a DRY KISS::.
> >
  

FW: [DISCUSSION] How to deal with runtime dependencies

[Markus Geiß]

Hey all,

We've started a thread at our dev list and forgot to send it to the
general incubator list too.
Any opinion is appreciated, you can find the original message below.

Best,

Markus

.::YAGNI likes a DRY KISS::.

> From: markus.ge...@live.de
> To: d...@fineract.incubator.apache.org
> Subject: [DISCUSSION] How to deal with runtime dependencies
> Date: Mon, 8 Feb 2016 14:12:04 +0100
> 
> Hey all,
> 
> hope this finds you well.
> 
> I thought instead of discussing this on top of pull request, because it is 
> more
> than just the JDBC driver, it is the right time to create a new thread.
> 
> We are currently using MySQL's Connector/J and Hibernate's EntityManager at
> runtime as the JDBC driver and JPA implementation. Our source code is not
> depending on both.
> 
> It would create a huge effort to replace both for test and production 
> environments.
> 
> The questions is:
> 
> Would it be compliant with the license policies if we omit them for our source
> release, but keeping them for our own integration tests.
> 
> If somebody is creating a deployable distribution, the expectation is that 
> whomever
> is creating the distribution can decide what he wants to use.
> 
> Best,
> 
> Markus
> 
> .::YAGNI likes a DRY KISS::.
  

Re: FW: [DISCUSSION] How to deal with runtime dependencies

[Jacques Nadeau]

I've used this as reference previously:

http://www.apache.org/legal/resolved.html#prohibited

Specifically this sentence:

"...For example, using a GPL'ed tool during the build is OK."

That would suggest that using GPL tools for build and test should be okay.

I'll let others address the distribution of optional components question in
great detail. My sense is this is primarily focused on how "optional" the
undistributable component is.

On Wed, Feb 10, 2016 at 12:56 AM, Markus Geiß  wrote:

> Hey all,
>
> We've started a thread at our dev list and forgot to send it to the
> general incubator list too.
> Any opinion is appreciated, you can find the original message below.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > From: markus.ge...@live.de
> > To: d...@fineract.incubator.apache.org
> > Subject: [DISCUSSION] How to deal with runtime dependencies
> > Date: Mon, 8 Feb 2016 14:12:04 +0100
> >
> > Hey all,
> >
> > hope this finds you well.
> >
> > I thought instead of discussing this on top of pull request, because it
> is more
> > than just the JDBC driver, it is the right time to create a new thread.
> >
> > We are currently using MySQL's Connector/J and Hibernate's EntityManager
> at
> > runtime as the JDBC driver and JPA implementation. Our source code is not
> > depending on both.
> >
> > It would create a huge effort to replace both for test and production
> environments.
> >
> > The questions is:
> >
> > Would it be compliant with the license policies if we omit them for our
> source
> > release, but keeping them for our own integration tests.
> >
> > If somebody is creating a deployable distribution, the expectation is
> that whomever
> > is creating the distribution can decide what he wants to use.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
>

Re: DRAFT report February 2016 -- please review

[Marvin Humphrey]

Greets,

The Metron report, pasted below, was filed late (partly due to wiki
permission issues), but I see from the dev@metron archives that it was
prepared last week.

I also see that Billie Rinaldi approved the report in an email, so
I've taken the liberty of signing off on her behalf.

I'm happy to help out a new podling but please get in the habit of
filing your reports on time. :)

Marvin Humphrey


Metron

Metron integrates a variety of open source big data technologies in order to
offer a centralized tool for security monitoring and analysis. Metron
provides capabilities for log aggregation, full packet capture indexing,
storage, advanced behavioral analytics and data enrichment, while applying
the most current threat-intelligence information to security telemetry
within a single platform.

Metron has been incubating since 12-08-2015

Three most important issues to address in the move towards
Graduation.

  - Building a diverse community of developers for Metron
  - Getting security practitioners to provide feedback on requirements
  - Make an Apache release

Any issues that the Incubator PMC or ASF Board might wish/need to be aware
of?

  - We are currently trying to produce the first Apache release of Metron
  - We would like to request Apache infrastructure (a Jenkins server) for CI

How has the community developed since the last report

  - We started working on implementing a variety of new features on Metron
  - We did a Meetup in the DC area jointly with Capital One.  We had over 75
people in attendance with many expressing interest in joining the Metron
project

How has the project developed since the last report

  - This month we have closed 7 key Jiras and built up scripts for standing
up an integration and test environment for Metron that anyone in the
community can take advantage of

Signed-off-by:

  [x](metron) Billie Rinaldi
  [ ](metron) Chris Mattmann
  [ ](metron) Owen O'Malley
  [ ](metron) P. Taylor Goetz
  [ ](metron) Vinod K

Shepherd/Mentor notes:

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

Re: FW: [DISCUSSION] How to deal with runtime dependencies

[Roman Shaposhnik]

On Wed, Feb 10, 2016 at 12:56 AM, Markus Geiß  wrote:
> Hey all,
>
> We've started a thread at our dev list and forgot to send it to the
> general incubator list too.
> Any opinion is appreciated, you can find the original message below.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
>> From: markus.ge...@live.de
>> To: d...@fineract.incubator.apache.org
>> Subject: [DISCUSSION] How to deal with runtime dependencies
>> Date: Mon, 8 Feb 2016 14:12:04 +0100
>>
>> Hey all,
>>
>> hope this finds you well.
>>
>> I thought instead of discussing this on top of pull request, because it is 
>> more
>> than just the JDBC driver, it is the right time to create a new thread.
>>
>> We are currently using MySQL's Connector/J and Hibernate's EntityManager at
>> runtime as the JDBC driver and JPA implementation. Our source code is not
>> depending on both.
>>
>> It would create a huge effort to replace both for test and production 
>> environments.
>>
>> The questions is:
>>
>> Would it be compliant with the license policies if we omit them for our 
>> source
>> release, but keeping them for our own integration tests.
>>
>> If somebody is creating a deployable distribution, the expectation is that 
>> whomever
>> is creating the distribution can decide what he wants to use.

The devil is in the details. Can you show a branch with this solution to the
problem prototyped?

Thanks,
Roman.

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