Re: [board report] Apache NiFi - July 2019

[Jeff]

Russell,

NIFI-5176 [1] is tracking Java 11 build compatibility for NiFi.  PR-3404
[2] is a work-in-progress PR that I welcome review and testing from anyone
in the community.  From PR 3404, several other PRs have been extracted to
prepare NiFi for Java 11 compatibility, and the JIRAs driving those PRs are
linked to NIFI-5176.

The current release of NiFi (and going back to NiFi 1.7.0) although built
with Java 8, will run on Java 11.

if you have any questions or concerns with NiFi on built or run on Java 11,
I'd be happy to discuss in a separate thread on the dev list.

[1] https://issues.apache.org/jira/browse/NIFI-5176
[2] https://github.com/apache/nifi/pull/3404

On Wed, Jul 10, 2019 at 5:28 PM Russell Bateman 
wrote:

> I mulled over whether it's appropriate to ask within this context. I
> guess I'll ask. Slap me if I have badly chosen, but where is NiFi
> respective to "modern" JDK versions? Is that too much detail for the
> audience of this periodic report?
>
> Thanks.
>
> On 7/10/19 11:15 AM, Joe Witt wrote:
> > Team,
> >
> > I was running late so submitted the report already.  Here is what I sent
> to
> > the board for Apache NiFi July 2019 report.  Great work and great
> progress
> > all!
> >
> >
> >
> > ## Description:
> >   - Apache NiFi is an easy to use, powerful, and reliable system to
> process
> > and
> > distribute data.
> >   - Apache NiFi MiNiFi is an edge data collection agent built to
> seamlessly
> > integrate with and leverage the command and control of NiFi. There
> are
> > both
> > Java and C++ implementations.
> >   - Apache NiFi Registry is a centralized registry for key configuration
> > items
> > including flow versions, assets, and extensions for Apache NiFi and
> > Apache
> > MiNiFi.
> >   - Apache NiFi Nar Maven Plugin is a release artifact used for
> supporting
> > the
> > NiFi classloader isolation model.
> >   - Apache NiFi Flow Design System is a theme-able set of high quality UI
> > components and utilities for use across the various Apache NiFi web
> > applications in order to provide a more consistent user experience.
> >
> > ## Issues:
> >   - There are no issues requiring board attention at this time.
> >
> > ## Activity:
> >   - Released Apache NiFi Registry 0.4.0 which allows storage of
> extensions
> > which
> > is a critical step towards us breaking apart the monolithic release
> of
> > today
> > resulting in smaller binaries in Apache infra a mirrors and will also
> > bring
> > a better user experience for updating live running NiFi clusters and
> > operations in container based environments.
> >   - The community is working the release preparation and voting process
> for
> > Apache NiFi MiNiFi CPP 0.6.1.
> >   - Apache NiFi 0.10.0 is progressing nicely with nearly 200 JIRAs
> already
> > included.  This brings powerful features such as sourcing extensions
> from
> > the latest NiFi Registry at runtime, far better model for
> paramaterized
> > version controlled flows, Java 11 compatibility, and much more.
> >
> > ## Health report:
> >   - Health of the community remains strong with many active release
> lines,
> > feature development, active user and developer base including new
> > participants and continued participants.
> >   - We see considerable commentary on Apache NiFi in the form of meetups,
> > conferences, training, and talks including from folks at Google,
> Cloudera
> > and others. A recent tweet from a Ford Motor Company employee says it
> > best
> > "Love, love, love @apachenifi   Using MiNiFi opens up IOT innovation
> in
> > amazing ways.  Every IOT device manufacturer, including automotive,
> > should consider opening up API's to let developers do their thing!
> > Bringing value to your product! "
> >
> > ## PMC changes:
> >
> >   - Currently 30 PMC members.
> >   - Peter Wicks was added to the PMC on Wed May 29 2019
> >
> > ## Committer base changes:
> >
> >   - Currently 43 committers.
> >   - Arpad Boda was added as a committer on Thu May 23 2019
> >
> > ## Releases:
> >
> >   - Apache NiFi Registry 0.4.0 was released on Mon May 20 2019
> >
> > ## Mailing list activity:
> >
> >   - Activity on the mailing lists remains high with a mixture of new
> users,
> > contributors, and deeper more experienced users and contributors
> sparking
> > discussion and questions and filing bugs or new features.
> >
> >   - We do see a significant drop in users list usage while dev and issues
> > remains busy and even growing.  Meanwhile we see strong growth in our
> > slack channel and it is very user centric.
> >
> >   - Slack Channel Usage: apachenifi.slack.com
> >- 394 users currently in the room.  This has grown weekly.
> >
> >   - us...@nifi.apache.org:
> >  - 693 subscribers (up 18 in the last 3 months):
> >  - 447 emails sent to list (800 in previous quarter)
> >
> >   - dev@nifi.apache.org:
> >  - 443 subscribers (down -1 

Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

[Mike Thomsen]

I agree. It's very well thought out. One change to consider is splitting
the extensions further into two separate repos. One that would serve as a
standard library of sorts for other component developers and another that
would include everything else. Things like the Record API would go into the
former so that we could have a more conservative release schedule going
forward with those components.

On Wed, Jul 10, 2019 at 4:17 PM Andy LoPresto  wrote:

> Thanks Kevin, this looks really promising.
>
> Updating the link here as I think the page may have moved:
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+Project+and+Repository+Restructuring
> <
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+Project+and+Repository+Restructuring
> >
>
> Andy LoPresto
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Jul 10, 2019, at 12:08 PM, Kevin Doran  wrote:
> >
> > Hi NiFi Dev Community,
> >
> > Jeff Storck, Bryan Bende, and I have been collaborating back and forth
> > on a proposal for how to restructure the NiFi source code into smaller
> > Maven projects and repositories based on the discussion that took
> > place awhile back on this thread. I'm reviving this older thread in
> > order to share that proposal with the community and generate farther
> > discussion about at solidifying a destination and a plan for how to
> > get there.
> >
> > Specifically, the proposal we've started working on has three parts:
> >
> > 1. Goals (more or less a summary of the earlier discussion that took
> > place on this thread)
> > 2. Proposed end state of the new Maven project and repository structure
> > 3. Proposed approach for how to get from where we are today to the
> > desired end state
> >
> > The proposal is on the Apache NiFi Wiki [1], so that we can all
> > collaborate on it or leave comments there.
> >
> > [1]
> https://cwiki.apache.org/confluence/display/NIFIREG/NiFi+Project+and+Repository+Restructuring
> >
> > Thanks,
> > Kevin, Jeff, and Bryan
> >
> > On Thu, May 30, 2019 at 1:31 PM Kevin Doran  wrote:
> >>
> >> I am also in favor of splitting the nifi maven project up into smaller
> >> projects with independent release cycles in order to decouple
> >> development at well defined boundaries/interfaces and also to
> >> facilitate code reuse.
> >>
> >> In anticipation of eventually working towards a NiFi 2.0 that
> >> introduces bigger changes for developers and users, I've started work
> >> on a nifi-commons project in which I've extracted out some of the code
> >> that originally got ported from NiFi -> NiFi Registry, and now exists
> >> as similar code in both projects, into a standalone modular library.
> >> That premilinary work is here on my personal github account for now
> >> [1].
> >>
> >> So far, it only contains some security code in a submodule, and is a
> >> WIP (more work coming when I have time), but the idea is nifi-commons
> >> could have several libraries/modules and would be released
> >> periodically to use across nifi and registry. If we are talking about
> >> spliting the nifi project into framework and extensions, then
> >> nifi-commons might be a good home for code that needs to be shared
> >> across those two sub projects as well, such as the nifi-api bits Joe
> >> mentioned.
> >>
> >> As part of this larger effort, I would be happy to help get a
> >> nifi-commons repository started in Apache where we can move shared
> >> code such as nifi-api to prepare for splitting nifi-framework and
> >> nifi-extensions. It also occurs to me that if nifi-framework and
> >> nifi-extensions are being released independently, nifi-assembly should
> >> probably just become a project that pulls in and assembles the latest
> >> releases of framework and extensions.
> >>
> >> Overall, I think this would be beneficial for most of the work going
> >> on in Apache NiFi, which would not have to cut across these different
> >> project and therefore would be easier to code, test, build, and
> >> release. However, the level of difficulty will increase for changes
> >> that will need to span multiple projects, though those are fewer in
> >> number, so overall I think it would be a net win for the dev
> >> community.
> >>
> >> [1] https://github.com/kevdoran/nifi-commons
> >>
> >> Thanks,
> >> Kevin
> >>
> >> On Thu, May 30, 2019 at 12:17 PM Andy LoPresto 
> wrote:
> >>>
> >>> I am a strong +1 on the separation and reducing the build time. With
> that in mind, I think the process I brought up yesterday [1] of signing our
> artifacts with GPG as part of the Maven build is paramount, because we
> would now be consuming core code across multiple projects/repositories, so
> there is even less guarantee the code is coming from “us”.
> >>>
> >>> [1]
> https://lists.apache.org/thread.html/5974971939c539c34148d494f11e8bcf0640c440ce5e7a768ee9db01@%3Cdev.nifi.apache.org%3E
> <
> 

Re: [board report] Apache NiFi - July 2019

[Russell Bateman]

I mulled over whether it's appropriate to ask within this context. I 
guess I'll ask. Slap me if I have badly chosen, but where is NiFi 
respective to "modern" JDK versions? Is that too much detail for the 
audience of this periodic report?


Thanks.

On 7/10/19 11:15 AM, Joe Witt wrote:

Team,

I was running late so submitted the report already.  Here is what I sent to
the board for Apache NiFi July 2019 report.  Great work and great progress
all!



## Description:
  - Apache NiFi is an easy to use, powerful, and reliable system to process
and
distribute data.
  - Apache NiFi MiNiFi is an edge data collection agent built to seamlessly
integrate with and leverage the command and control of NiFi. There are
both
Java and C++ implementations.
  - Apache NiFi Registry is a centralized registry for key configuration
items
including flow versions, assets, and extensions for Apache NiFi and
Apache
MiNiFi.
  - Apache NiFi Nar Maven Plugin is a release artifact used for supporting
the
NiFi classloader isolation model.
  - Apache NiFi Flow Design System is a theme-able set of high quality UI
components and utilities for use across the various Apache NiFi web
applications in order to provide a more consistent user experience.

## Issues:
  - There are no issues requiring board attention at this time.

## Activity:
  - Released Apache NiFi Registry 0.4.0 which allows storage of extensions
which
is a critical step towards us breaking apart the monolithic release of
today
resulting in smaller binaries in Apache infra a mirrors and will also
bring
a better user experience for updating live running NiFi clusters and
operations in container based environments.
  - The community is working the release preparation and voting process for
Apache NiFi MiNiFi CPP 0.6.1.
  - Apache NiFi 0.10.0 is progressing nicely with nearly 200 JIRAs already
included.  This brings powerful features such as sourcing extensions from
the latest NiFi Registry at runtime, far better model for paramaterized
version controlled flows, Java 11 compatibility, and much more.

## Health report:
  - Health of the community remains strong with many active release lines,
feature development, active user and developer base including new
participants and continued participants.
  - We see considerable commentary on Apache NiFi in the form of meetups,
conferences, training, and talks including from folks at Google, Cloudera
and others. A recent tweet from a Ford Motor Company employee says it
best
"Love, love, love @apachenifi   Using MiNiFi opens up IOT innovation in
amazing ways.  Every IOT device manufacturer, including automotive,
should consider opening up API's to let developers do their thing!
Bringing value to your product! "

## PMC changes:

  - Currently 30 PMC members.
  - Peter Wicks was added to the PMC on Wed May 29 2019

## Committer base changes:

  - Currently 43 committers.
  - Arpad Boda was added as a committer on Thu May 23 2019

## Releases:

  - Apache NiFi Registry 0.4.0 was released on Mon May 20 2019

## Mailing list activity:

  - Activity on the mailing lists remains high with a mixture of new users,
contributors, and deeper more experienced users and contributors sparking
discussion and questions and filing bugs or new features.

  - We do see a significant drop in users list usage while dev and issues
remains busy and even growing.  Meanwhile we see strong growth in our
slack channel and it is very user centric.

  - Slack Channel Usage: apachenifi.slack.com
   - 394 users currently in the room.  This has grown weekly.

  - us...@nifi.apache.org:
 - 693 subscribers (up 18 in the last 3 months):
 - 447 emails sent to list (800 in previous quarter)

  - dev@nifi.apache.org:
 - 443 subscribers (down -1 in the last 3 months):
 - 357 emails sent to list (417 in previous quarter)

  - iss...@nifi.apache.org:
 - 56 subscribers (up 0 in the last 3 months):
 - 5371 emails sent to list (4140 in previous quarter)


## JIRA activity:

  - 274 JIRA tickets created in the last 3 months
  - 188 JIRA tickets closed/resolved in the last 3 months



Thanks
Joe

Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

[Andy LoPresto]

Thanks Kevin, this looks really promising. 

Updating the link here as I think the page may have moved: 
https://cwiki.apache.org/confluence/display/NIFI/NiFi+Project+and+Repository+Restructuring
 


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jul 10, 2019, at 12:08 PM, Kevin Doran  wrote:
> 
> Hi NiFi Dev Community,
> 
> Jeff Storck, Bryan Bende, and I have been collaborating back and forth
> on a proposal for how to restructure the NiFi source code into smaller
> Maven projects and repositories based on the discussion that took
> place awhile back on this thread. I'm reviving this older thread in
> order to share that proposal with the community and generate farther
> discussion about at solidifying a destination and a plan for how to
> get there.
> 
> Specifically, the proposal we've started working on has three parts:
> 
> 1. Goals (more or less a summary of the earlier discussion that took
> place on this thread)
> 2. Proposed end state of the new Maven project and repository structure
> 3. Proposed approach for how to get from where we are today to the
> desired end state
> 
> The proposal is on the Apache NiFi Wiki [1], so that we can all
> collaborate on it or leave comments there.
> 
> [1] 
> https://cwiki.apache.org/confluence/display/NIFIREG/NiFi+Project+and+Repository+Restructuring
> 
> Thanks,
> Kevin, Jeff, and Bryan
> 
> On Thu, May 30, 2019 at 1:31 PM Kevin Doran  wrote:
>> 
>> I am also in favor of splitting the nifi maven project up into smaller
>> projects with independent release cycles in order to decouple
>> development at well defined boundaries/interfaces and also to
>> facilitate code reuse.
>> 
>> In anticipation of eventually working towards a NiFi 2.0 that
>> introduces bigger changes for developers and users, I've started work
>> on a nifi-commons project in which I've extracted out some of the code
>> that originally got ported from NiFi -> NiFi Registry, and now exists
>> as similar code in both projects, into a standalone modular library.
>> That premilinary work is here on my personal github account for now
>> [1].
>> 
>> So far, it only contains some security code in a submodule, and is a
>> WIP (more work coming when I have time), but the idea is nifi-commons
>> could have several libraries/modules and would be released
>> periodically to use across nifi and registry. If we are talking about
>> spliting the nifi project into framework and extensions, then
>> nifi-commons might be a good home for code that needs to be shared
>> across those two sub projects as well, such as the nifi-api bits Joe
>> mentioned.
>> 
>> As part of this larger effort, I would be happy to help get a
>> nifi-commons repository started in Apache where we can move shared
>> code such as nifi-api to prepare for splitting nifi-framework and
>> nifi-extensions. It also occurs to me that if nifi-framework and
>> nifi-extensions are being released independently, nifi-assembly should
>> probably just become a project that pulls in and assembles the latest
>> releases of framework and extensions.
>> 
>> Overall, I think this would be beneficial for most of the work going
>> on in Apache NiFi, which would not have to cut across these different
>> project and therefore would be easier to code, test, build, and
>> release. However, the level of difficulty will increase for changes
>> that will need to span multiple projects, though those are fewer in
>> number, so overall I think it would be a net win for the dev
>> community.
>> 
>> [1] https://github.com/kevdoran/nifi-commons
>> 
>> Thanks,
>> Kevin
>> 
>> On Thu, May 30, 2019 at 12:17 PM Andy LoPresto  wrote:
>>> 
>>> I am a strong +1 on the separation and reducing the build time. With that 
>>> in mind, I think the process I brought up yesterday [1] of signing our 
>>> artifacts with GPG as part of the Maven build is paramount, because we 
>>> would now be consuming core code across multiple projects/repositories, so 
>>> there is even less guarantee the code is coming from “us”.
>>> 
>>> [1] 
>>> https://lists.apache.org/thread.html/5974971939c539c34148d494f11e8bcf0640c440ce5e7a768ee9db01@%3Cdev.nifi.apache.org%3E
>>>  
>>> 
>>> 
>>> Andy LoPresto
>>> alopre...@apache.org
>>> alopresto.apa...@gmail.com
>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>> 
 On May 30, 2019, at 9:15 AM, Brandon DeVries  wrote:
 
 In regards to "We 'could' also split out the 'nifi-api'...", NiFi 2.0 would
 also be a good time to look at more clearly defining the separation between
 the UI and the framework.  Where nifi-api is the contract between the
 extensions and the framework, the NiFi Rest api is the contract between the

Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

[Kevin Doran]

Hi NiFi Dev Community,

Jeff Storck, Bryan Bende, and I have been collaborating back and forth
on a proposal for how to restructure the NiFi source code into smaller
Maven projects and repositories based on the discussion that took
place awhile back on this thread. I'm reviving this older thread in
order to share that proposal with the community and generate farther
discussion about at solidifying a destination and a plan for how to
get there.

Specifically, the proposal we've started working on has three parts:

1. Goals (more or less a summary of the earlier discussion that took
place on this thread)
2. Proposed end state of the new Maven project and repository structure
3. Proposed approach for how to get from where we are today to the
desired end state

The proposal is on the Apache NiFi Wiki [1], so that we can all
collaborate on it or leave comments there.

[1] 
https://cwiki.apache.org/confluence/display/NIFIREG/NiFi+Project+and+Repository+Restructuring

Thanks,
Kevin, Jeff, and Bryan

On Thu, May 30, 2019 at 1:31 PM Kevin Doran  wrote:
>
> I am also in favor of splitting the nifi maven project up into smaller
> projects with independent release cycles in order to decouple
> development at well defined boundaries/interfaces and also to
> facilitate code reuse.
>
> In anticipation of eventually working towards a NiFi 2.0 that
> introduces bigger changes for developers and users, I've started work
> on a nifi-commons project in which I've extracted out some of the code
> that originally got ported from NiFi -> NiFi Registry, and now exists
> as similar code in both projects, into a standalone modular library.
> That premilinary work is here on my personal github account for now
> [1].
>
> So far, it only contains some security code in a submodule, and is a
> WIP (more work coming when I have time), but the idea is nifi-commons
> could have several libraries/modules and would be released
> periodically to use across nifi and registry. If we are talking about
> spliting the nifi project into framework and extensions, then
> nifi-commons might be a good home for code that needs to be shared
> across those two sub projects as well, such as the nifi-api bits Joe
> mentioned.
>
> As part of this larger effort, I would be happy to help get a
> nifi-commons repository started in Apache where we can move shared
> code such as nifi-api to prepare for splitting nifi-framework and
> nifi-extensions. It also occurs to me that if nifi-framework and
> nifi-extensions are being released independently, nifi-assembly should
> probably just become a project that pulls in and assembles the latest
> releases of framework and extensions.
>
> Overall, I think this would be beneficial for most of the work going
> on in Apache NiFi, which would not have to cut across these different
> project and therefore would be easier to code, test, build, and
> release. However, the level of difficulty will increase for changes
> that will need to span multiple projects, though those are fewer in
> number, so overall I think it would be a net win for the dev
> community.
>
> [1] https://github.com/kevdoran/nifi-commons
>
> Thanks,
> Kevin
>
> On Thu, May 30, 2019 at 12:17 PM Andy LoPresto  wrote:
> >
> > I am a strong +1 on the separation and reducing the build time. With that 
> > in mind, I think the process I brought up yesterday [1] of signing our 
> > artifacts with GPG as part of the Maven build is paramount, because we 
> > would now be consuming core code across multiple projects/repositories, so 
> > there is even less guarantee the code is coming from “us”.
> >
> > [1] 
> > https://lists.apache.org/thread.html/5974971939c539c34148d494f11e8bcf0640c440ce5e7a768ee9db01@%3Cdev.nifi.apache.org%3E
> >  
> > 
> >
> > Andy LoPresto
> > alopre...@apache.org
> > alopresto.apa...@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > > On May 30, 2019, at 9:15 AM, Brandon DeVries  wrote:
> > >
> > > In regards to "We 'could' also split out the 'nifi-api'...", NiFi 2.0 
> > > would
> > > also be a good time to look at more clearly defining the separation 
> > > between
> > > the UI and the framework.  Where nifi-api is the contract between the
> > > extensions and the framework, the NiFi Rest api is the contract between 
> > > the
> > > UI and framework...  These pieces could potentially be built  / deployed /
> > > updated independently.
> > >
> > > On Thu, May 30, 2019 at 11:39 AM Jeff  wrote:
> > >
> > >> In the same category of challenges that Peter pointed out, it might be
> > >> difficult for Travis to build the "framework" and "extensions" projects 
> > >> if
> > >> there are changes in a PR that affect both projects.
> > >>
> > >> Is there a good way in Travis to have the workspace/maven repo shared
> > >> between projects in a single build?
> > >>
> > >> It's probably always 

Re: [board report] Apache NiFi - July 2019

[Joe Witt]

good catch!   will fix

On Wed, Jul 10, 2019, 2:08 PM John McGinn  wrote:

> Joe,
>
> Minor squabble, but, NiFi is getting setup for 1.10.0 release, not 0.10.0
> release.
>
>
>
> On Wednesday, July 10, 2019, 1:16:04 PM EDT, Joe Witt 
> wrote:
>
> Team,
>
> I was running late so submitted the report already. Here is what I sent to
> the board for Apache NiFi July 2019 report. Great work and great progress
> all!
>
> ...
>
> ## Activity:
> - Apache NiFi 0.10.0 is progressing nicely with nearly 200 JIRAs already
> included. This brings powerful features such as sourcing extensions from
> the latest NiFi Registry at runtime, far better model for paramaterized
> version controlled flows, Java 11 compatibility, and much more.
>

Re: [board report] Apache NiFi - July 2019

[John McGinn]

 Joe,

Minor squabble, but, NiFi is getting setup for 1.10.0 release, not 0.10.0 
release. 



On Wednesday, July 10, 2019, 1:16:04 PM EDT, Joe Witt  
wrote:

Team,

I was running late so submitted the report already. Here is what I sent to
the board for Apache NiFi July 2019 report. Great work and great progress
all!

...

## Activity:
- Apache NiFi 0.10.0 is progressing nicely with nearly 200 JIRAs already
 included. This brings powerful features such as sourcing extensions from
 the latest NiFi Registry at runtime, far better model for paramaterized
 version controlled flows, Java 11 compatibility, and much more.  

Re: [board report] Apache NiFi - July 2019

[Andy LoPresto]

Thanks for taking care of this Joe. Looks great. 

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jul 10, 2019, at 10:15 AM, Joe Witt  wrote:
> 
> Team,
> 
> I was running late so submitted the report already.  Here is what I sent to
> the board for Apache NiFi July 2019 report.  Great work and great progress
> all!
> 
> 
> 
> ## Description:
> - Apache NiFi is an easy to use, powerful, and reliable system to process
> and
>   distribute data.
> - Apache NiFi MiNiFi is an edge data collection agent built to seamlessly
>   integrate with and leverage the command and control of NiFi. There are
> both
>   Java and C++ implementations.
> - Apache NiFi Registry is a centralized registry for key configuration
> items
>   including flow versions, assets, and extensions for Apache NiFi and
> Apache
>   MiNiFi.
> - Apache NiFi Nar Maven Plugin is a release artifact used for supporting
> the
>   NiFi classloader isolation model.
> - Apache NiFi Flow Design System is a theme-able set of high quality UI
>   components and utilities for use across the various Apache NiFi web
>   applications in order to provide a more consistent user experience.
> 
> ## Issues:
> - There are no issues requiring board attention at this time.
> 
> ## Activity:
> - Released Apache NiFi Registry 0.4.0 which allows storage of extensions
> which
>   is a critical step towards us breaking apart the monolithic release of
> today
>   resulting in smaller binaries in Apache infra a mirrors and will also
> bring
>   a better user experience for updating live running NiFi clusters and
>   operations in container based environments.
> - The community is working the release preparation and voting process for
>   Apache NiFi MiNiFi CPP 0.6.1.
> - Apache NiFi 0.10.0 is progressing nicely with nearly 200 JIRAs already
>   included.  This brings powerful features such as sourcing extensions from
>   the latest NiFi Registry at runtime, far better model for paramaterized
>   version controlled flows, Java 11 compatibility, and much more.
> 
> ## Health report:
> - Health of the community remains strong with many active release lines,
>   feature development, active user and developer base including new
>   participants and continued participants.
> - We see considerable commentary on Apache NiFi in the form of meetups,
>   conferences, training, and talks including from folks at Google, Cloudera
>   and others. A recent tweet from a Ford Motor Company employee says it
> best
>   "Love, love, love @apachenifi   Using MiNiFi opens up IOT innovation in
>   amazing ways.  Every IOT device manufacturer, including automotive,
>   should consider opening up API's to let developers do their thing!
>   Bringing value to your product! "
> 
> ## PMC changes:
> 
> - Currently 30 PMC members.
> - Peter Wicks was added to the PMC on Wed May 29 2019
> 
> ## Committer base changes:
> 
> - Currently 43 committers.
> - Arpad Boda was added as a committer on Thu May 23 2019
> 
> ## Releases:
> 
> - Apache NiFi Registry 0.4.0 was released on Mon May 20 2019
> 
> ## Mailing list activity:
> 
> - Activity on the mailing lists remains high with a mixture of new users,
>   contributors, and deeper more experienced users and contributors sparking
>   discussion and questions and filing bugs or new features.
> 
> - We do see a significant drop in users list usage while dev and issues
>   remains busy and even growing.  Meanwhile we see strong growth in our
>   slack channel and it is very user centric.
> 
> - Slack Channel Usage: apachenifi.slack.com
>  - 394 users currently in the room.  This has grown weekly.
> 
> - us...@nifi.apache.org:
>- 693 subscribers (up 18 in the last 3 months):
>- 447 emails sent to list (800 in previous quarter)
> 
> - dev@nifi.apache.org:
>- 443 subscribers (down -1 in the last 3 months):
>- 357 emails sent to list (417 in previous quarter)
> 
> - iss...@nifi.apache.org:
>- 56 subscribers (up 0 in the last 3 months):
>- 5371 emails sent to list (4140 in previous quarter)
> 
> 
> ## JIRA activity:
> 
> - 274 JIRA tickets created in the last 3 months
> - 188 JIRA tickets closed/resolved in the last 3 months
> 
> 
> 
> Thanks
> Joe

[board report] Apache NiFi - July 2019

[Joe Witt]

Team,

I was running late so submitted the report already.  Here is what I sent to
the board for Apache NiFi July 2019 report.  Great work and great progress
all!



## Description:
 - Apache NiFi is an easy to use, powerful, and reliable system to process
and
   distribute data.
 - Apache NiFi MiNiFi is an edge data collection agent built to seamlessly
   integrate with and leverage the command and control of NiFi. There are
both
   Java and C++ implementations.
 - Apache NiFi Registry is a centralized registry for key configuration
items
   including flow versions, assets, and extensions for Apache NiFi and
Apache
   MiNiFi.
 - Apache NiFi Nar Maven Plugin is a release artifact used for supporting
the
   NiFi classloader isolation model.
 - Apache NiFi Flow Design System is a theme-able set of high quality UI
   components and utilities for use across the various Apache NiFi web
   applications in order to provide a more consistent user experience.

## Issues:
 - There are no issues requiring board attention at this time.

## Activity:
 - Released Apache NiFi Registry 0.4.0 which allows storage of extensions
which
   is a critical step towards us breaking apart the monolithic release of
today
   resulting in smaller binaries in Apache infra a mirrors and will also
bring
   a better user experience for updating live running NiFi clusters and
   operations in container based environments.
 - The community is working the release preparation and voting process for
   Apache NiFi MiNiFi CPP 0.6.1.
 - Apache NiFi 0.10.0 is progressing nicely with nearly 200 JIRAs already
   included.  This brings powerful features such as sourcing extensions from
   the latest NiFi Registry at runtime, far better model for paramaterized
   version controlled flows, Java 11 compatibility, and much more.

## Health report:
 - Health of the community remains strong with many active release lines,
   feature development, active user and developer base including new
   participants and continued participants.
 - We see considerable commentary on Apache NiFi in the form of meetups,
   conferences, training, and talks including from folks at Google, Cloudera
   and others. A recent tweet from a Ford Motor Company employee says it
best
   "Love, love, love @apachenifi   Using MiNiFi opens up IOT innovation in
   amazing ways.  Every IOT device manufacturer, including automotive,
   should consider opening up API's to let developers do their thing!
   Bringing value to your product! "

## PMC changes:

 - Currently 30 PMC members.
 - Peter Wicks was added to the PMC on Wed May 29 2019

## Committer base changes:

 - Currently 43 committers.
 - Arpad Boda was added as a committer on Thu May 23 2019

## Releases:

 - Apache NiFi Registry 0.4.0 was released on Mon May 20 2019

## Mailing list activity:

 - Activity on the mailing lists remains high with a mixture of new users,
   contributors, and deeper more experienced users and contributors sparking
   discussion and questions and filing bugs or new features.

 - We do see a significant drop in users list usage while dev and issues
   remains busy and even growing.  Meanwhile we see strong growth in our
   slack channel and it is very user centric.

 - Slack Channel Usage: apachenifi.slack.com
  - 394 users currently in the room.  This has grown weekly.

 - us...@nifi.apache.org:
- 693 subscribers (up 18 in the last 3 months):
- 447 emails sent to list (800 in previous quarter)

 - dev@nifi.apache.org:
- 443 subscribers (down -1 in the last 3 months):
- 357 emails sent to list (417 in previous quarter)

 - iss...@nifi.apache.org:
- 56 subscribers (up 0 in the last 3 months):
- 5371 emails sent to list (4140 in previous quarter)


## JIRA activity:

 - 274 JIRA tickets created in the last 3 months
 - 188 JIRA tickets closed/resolved in the last 3 months



Thanks
Joe

Re: What if only 1 of 3 travis jobs fails?

[Mike Thomsen]

If one of the builds passes, don't worry about it unless you happen to
notice that for some odd reason your contribution doesn't work under one of
the other language builds.

On Wed, Jul 10, 2019 at 7:21 AM Lars Winderling 
wrote:

> Dear core developers,
>
> I find myself often in a situation where 1 or 2 out of 3 travis jobs fail.
> So 1 or 2 of the jobs succeed anyway, the failing jobs only have some
> connection issue like failing to fetch some dependency jars.
> In that case I know, that the build was in pricinple successful, allthough
> in github it looks as if it simply failed.
> What should I do in that case? I couldn't find an explanation in the
> contribution guide, that's why I'm asking.
> Should I rather
> * re-trigger a build by a new push (e.g. using git commit --amend)
> * add a comment to the github issue like "In principle it works, only some
> jobs failed. Please just merge my stuff."
> * ask on the mailing list for someone to rebuild that job
> * don't do anything
> ?
>
> Thank you in advance for all your great work!
> Best,
> Lars
>

What if only 1 of 3 travis jobs fails?

[Lars Winderling]

Dear core developers,

I find myself often in a situation where 1 or 2 out of 3 travis jobs fail. So 1 
or 2 of the jobs succeed anyway, the
failing jobs only have some connection issue like failing to fetch some 
dependency jars.
In that case I know, that the build was in pricinple successful, allthough in 
github it looks as if it simply failed.
What should I do in that case? I couldn't find an explanation in the 
contribution guide, that's why I'm asking.
Should I rather
* re-trigger a build by a new push (e.g. using git commit --amend)
* add a comment to the github issue like "In principle it works, only some jobs 
failed. Please just merge my stuff."
* ask on the mailing list for someone to rebuild that job
* don't do anything
?

Thank you in advance for all your great work!
Best,
Lars


signature.asc
Description: This is a digitally signed message part

Re: [DISCUSS] Apache NiFi MiNiFi C++ 0.6.1

[Daniel Bakai]

I agree, I would not be comfortable with releasing a fix until it is
properly
tested, because there might well be other issues.

On Tue, 9 Jul 2019 at 18:54, Marc Parisi  wrote:

> Good find! I'm +1 on adding that fix piggy backed on the aforementioned
> test ticket. There are almost no tests on listen http and it has been a
> risk for some time.
>
> I'd like to avoid adding any fixes without those tests in 814 ( we'll end
> up fixing in master and cherry picking). Happy to help as time allows but I
> think this bug has been around long enough that we can suffer the time to
> add those tests if we want it fixed in 0.6.1
>
> On Tue, Jul 9, 2019, 12:24 PM Daniel Bakai 
> wrote:
>
> > Hi,
> >
> > I am working on https://issues.apache.org/jira/browse/MINIFICPP-814,
> > and unfortunately https support in ListenHTTP seems to be broken since
> > https://github.com/apache/nifi-minifi-cpp/pull/394 was merged, which
> > disabled SSL support in civetweb.
> > This unfortunately means that it is broken in 0.6.0 as well as on master.
> > I have verified this with the macOS binary release of 0.6.0.
> > I propose we discuss whether the fix for this (once, hopefully soon,
> ready)
> > be added to 0.6.1 as https://issues.apache.org/jira/browse/MINIFICPP-960
> >
> > Best,
> > Daniel
> >
> > On Sat, 6 Jul 2019 at 17:21, Arpad Boda  wrote:
> >
> > > As a result of this vote MiNiFi C++ 0.6.1 is going to be released soon
> > with
> > > the following scope:
> > > https://issues.apache.org/jira/browse/MINIFICPP-786
> > > https://issues.apache.org/jira/browse/MINIFICPP-933
> > > https://issues.apache.org/jira/browse/MINIFICPP-919
> > >
> > > I will do the RM duties.
> > >
> > > Regards,
> > > Arpad
> > >
> > > On Thu, Jun 27, 2019 at 3:00 PM Aldrin Piri 
> > wrote:
> > >
> > > > I agree with 786 for sure.  I apologize, I may have interpreted your
> > > > initial response a bit literally with regards to the "feature
> bearing"
> > > > JIRAs.  Just wanted to clarify that new features would not be in
> scope
> > > for
> > > > a fix version release, but in terms of adjusting the expected
> > > > functionality, totally onboard with that.
> > > >
> > > > On Thu, Jun 27, 2019 at 8:47 AM Jeremy Dyer 
> wrote:
> > > >
> > > > > Completely agree but isn’t MINIFICPP-786 an issue we could include
> as
> > > > part
> > > > > of that?
> > > > >
> > > > > On Wed, Jun 26, 2019 at 6:35 PM Aldrin Piri 
> > > > wrote:
> > > > >
> > > > > > I think the intent is for this to be a fix release and wouldn’t
> > > include
> > > > > > any new features.
> > > > > >
> > > > > > > On Jun 26, 2019, at 17:47, Jeremy Dyer 
> wrote:
> > > > > > >
> > > > > > > +1 it’s time and lots of feature bearing JIRAs have been
> resolved
> > > > > > >
> > > > > > > I do agree with with Arpad however on the inclusion of
> > > MINIFICPP-786
> > > > > > >
> > > > > > >> On Wed, Jun 26, 2019 at 5:37 PM Arpad Boda 
> > > > wrote:
> > > > > > >>
> > > > > > >> Happy to take RM roles as well.
> > > > > > >>
> > > > > > >>> On Wed, Jun 26, 2019 at 10:30 AM Arpad Boda <
> > ab...@cloudera.com>
> > > > > > wrote:
> > > > > > >>>
> > > > > > >>> +1.
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> As this release seems to be a Windows-focused, I would also
> > > > consider
> > > > > > >>> adding https://issues.apache.org/jira/browse/MINIFICPP-786
> > > > > > >>>
> > > > > > >>> On Tue, Jun 25, 2019 at 11:53 PM Marc Parisi <
> > > phroc...@apache.org>
> > > > > > >> wrote:
> > > > > > >>>
> > > > > >  Hi Everyone,
> > > > > > 
> > > > > >  I wanted to discuss releasing Apache NiFi MiNiFi C++ 0.6.1
> > with
> > > > some
> > > > > >  important bug fixes. We've had a few issues that impact
> > Windows
> > > > > users
> > > > > > >> and
> > > > > >  TLS with Raw Site To Site [1,2]. With these bugs addressed I
> > > think
> > > > > we
> > > > > >  should look to releasing 0.6.1.
> > > > > > 
> > > > > >  I would like to scope this bug fix release to only critical
> > and
> > > > > > blocker
> > > > > >  tickets found after 0.6.0. Let me know what you think or if
> > you
> > > > > think
> > > > > >  anything else should be included that is critical to user
> > > > > operations.
> > > > > > 
> > > > > >   My time is pretty fragmented but will try my best to take
> on
> > RM
> > > > > > duties
> > > > > >  unless someone would like to try their hand at it.
> > > > > > 
> > > > > >    Thanks,
> > > > > >    Marc Parisi
> > > > > > 
> > > > > >  [1] https://issues.apache.org/jira/browse/MINIFICPP-933
> > > > > >  [2] https://issues.apache.org/jira/browse/MINIFICPP-919
> > > > > > 
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
>