Re: Confluence wiki edit permission

[Andrew Psaltis]

Thanks Joe.

On Fri, Jul 7, 2017 at 11:38 PM, Joe Witt  wrote:

> Andrew
>
> You should now have permissions to edit the wiki.
>
> Thanks
> Joe
>
> On Fri, Jul 7, 2017 at 11:34 PM, Andrew Psaltis
>  wrote:
> > Hi,
> > I am interested in fixing an issue and adding more content in the
> > contributor guide on the wiki. One change is pretty simple an invalid
> URL.
> > The additional content I am thinking of at this time is around this
> process
> > in particular. I searched around trying to understand the process of how
> to
> > contribute wiki changes and the only references I can find were several
> > year old emails from this mailing list of folks asking to be given edit
> > permissions to contribute changes.
> >
> > Am I approaching this correctly? If not can you please point me in the
> > correct direction?
> >
> > --
> > Thanks,
> > Andrew
>



-- 
Thanks,
Andrew

Re: Confluence wiki edit permission

[Joe Witt]

Andrew

You should now have permissions to edit the wiki.

Thanks
Joe

On Fri, Jul 7, 2017 at 11:34 PM, Andrew Psaltis
 wrote:
> Hi,
> I am interested in fixing an issue and adding more content in the
> contributor guide on the wiki. One change is pretty simple an invalid URL.
> The additional content I am thinking of at this time is around this process
> in particular. I searched around trying to understand the process of how to
> contribute wiki changes and the only references I can find were several
> year old emails from this mailing list of folks asking to be given edit
> permissions to contribute changes.
>
> Am I approaching this correctly? If not can you please point me in the
> correct direction?
>
> --
> Thanks,
> Andrew

Confluence wiki edit permission

[Andrew Psaltis]

Hi,
I am interested in fixing an issue and adding more content in the
contributor guide on the wiki. One change is pretty simple an invalid URL.
The additional content I am thinking of at this time is around this process
in particular. I searched around trying to understand the process of how to
contribute wiki changes and the only references I can find were several
year old emails from this mailing list of folks asking to be given edit
permissions to contribute changes.

Am I approaching this correctly? If not can you please point me in the
correct direction?

-- 
Thanks,
Andrew

Re: Apache Rat and JSON files

[Chris Herrera]

I was just about to respond to myself, thanks Aldrin!

For anyone else searching just add this to the pom



org.apache.rat
apache-rat-plugin


src/test/resources/*.json





Regards,
Chris
> On Jul 7, 2017, at 4:06 PM, Aldrin Piri  wrote:
> 
> You can provide exclusions for files such as this in the pom.xml. Don't
> have specific path handy as on mobile but some grep'ing of other .json file
> names should show the way.
> On Fri, Jul 7, 2017 at 14:03 Chris Herrera 
> wrote:
> 
>> Hi All,
>> 
>> I am working on a contribution, and as part of it, there is a json file. I
>> cannot put comments in that json file and, as such, it does not pass the
>> rat check. Has anyone dealt with this issue before?
>> 
>> Regards,
>> Chris

Re: Apache Rat and JSON files

[Aldrin Piri]

You can provide exclusions for files such as this in the pom.xml. Don't
have specific path handy as on mobile but some grep'ing of other .json file
names should show the way.
On Fri, Jul 7, 2017 at 14:03 Chris Herrera 
wrote:

> Hi All,
>
> I am working on a contribution, and as part of it, there is a json file. I
> cannot put comments in that json file and, as such, it does not pass the
> rat check. Has anyone dealt with this issue before?
>
> Regards,
> Chris

Apache Rat and JSON files

[Chris Herrera]

Hi All,

I am working on a contribution, and as part of it, there is a json file. I 
cannot put comments in that json file and, as such, it does not pass the rat 
check. Has anyone dealt with this issue before?

Regards,
Chris

Re: RTC clarification

[Kevin Doran]

I am in favor of allowing Scenario A and leaving it up to the committer / 
submitter to determine if the review is sufficient to merge or if an additional 
review(s) should take place.

I think for committers will know the difference between, say, a documentation 
update or minor enhancement / fix to an extension vs. a major refactoring or 
re-write to part of the core framework.  In the latter case, the submitter 
probably wants someone familiar with that part of the code base to do a 
thorough review, and therefore will wait until that has a chance to occur prior 
to merging regardless of other approvals. I trust committers to make the 
correct call in that case, so I don't see a downside to Scenario A. And as 
others have stated, Scenario A has the upside of encouraging non-committers to 
get involved in code reviews... it will seem a little bit pointless for a 
non-committer to take the time to do a review if the project policy dictates it 
will not be binding and require a review by a committer anyway prior to merge.

Cheers,
Kevin

On 7/7/17, 10:10, "Joe Witt"  wrote:

We're looking at a possible set of scenarios comprised of a
'submitter' and a 'reviewer'.  There can be one or more reviewers.  A
submitter or reviewer is either a committer or is not a committer. If
there is at least one reviewer that is a committer it is a committer
reviewed scenario.  So with that in mind...

A) Committer submitted, Non-Committer reviewed = This can be merged in
the event of a positive review outcome.

B) Committer submitted, Committer reviewed = This can be merged in the
event of a positive review outcome.

C) Non-Committer submitted, Non-Committer reviewed = This cannot be
merged until there is at least one positive committer review.
However, that review is made easier for the committer as someone who
is still building merit in the community has already done work here
and further this is a great chance to work with/grow those folks in
the community.

D) Non-committer submitted, Committer reviewed = This can be merged in
the event of a positive review outcome.

Scenario B and D is easy and probably there is no discussion needed.
Same for scenario C as there has to be at least one committer involved
for the code to get pushed in the first place.  I suspect it is only
scenario A where we have some 'yeah but...' sort of thoughts going on.

I am favorable to us allowing scenario A to result in a merge because
at the end of the day there is a committer involved, heavily involved
in fact, and they've already been voted by the community to be a
committer.  That is a high bar as it should be.

The risk of bad commits getting through needs to be balanced against
the risk of community growth being hampered by slow review cycles.
Let's be honest, we need the help with review bandwidth.  It is really
hard to keep up and to my mind one of the best ways to annoy/deter
contributors from advancing is to make the time between contribution
to feedback take a long time.


On Fri, Jul 7, 2017 at 9:58 AM, Joe Skora  wrote:
> I agree that non-committer review make more sense if the reviewer has
> established some level of credibility and involvement in the community.
>
> Ultimately, the final committer has to be a community member and they will
> have final responsibility for the code being Apache compliant and NiFi
> ready, so even reviews by less well known members of the community should
> still be low risk.
>
> On Fri, Jul 7, 2017 at 9:24 AM, Bryan Bende  wrote:
>
>> I agree with encouraging reviews from everyone, but I lean towards
>> "binding" reviews coming from committers.
>>
>> If we allow any review to be binding, there could be completely
>> different levels of review that occur...
>>
>> There could be someone who isn't a committer yet, but has been
>> contributing already and will probably do a very thorough review of
>> someone's contribution, and there could be someone else who we never
>> interacted with us before and writes "+1 LGTM" on a PR and we have no
>> idea if they know what they are talking about or if they even tried
>> the contribution to see if it works. Obviously a committer can also
>> write "+1 LGTM", but I think when that comes from a committer it holds
>> more weight.
>>
>> I think we may also want to clarify if we are only talking about
>> "submitted by committer, reviewed by non-committer" or also talking
>> about "submitted by non-committer, reviewed by non-committer".
>>
>> For the first case I can see the argument that since the contribution
>> is from a committer who is already trusted, they can make the right
>> judgement call based on the review. Where as 

Re: MiNiFi Java as Windows Service

[Jeff Zemerick]

I submitted a pull request for running MiNiFi as a Windows service using
Commons Daemon's Procrun. Like winsw it supports more than just Java
applications so it should work for the C++ version as well. I went with it
due to it also being ASL and just due to personal familiarity. If there's a
strong desire for winsw instead let me know!

Since our edge locations are Windows environments I have also created a
Windows setup for MiNiFi using InnoSetup. The setup copies the required
files, installs the service, and removes the service when uninstalled. The
setup is buildable through Maven with a profile I added to the
minifi-assembly project (assuming InnoSetup is on your computer). If you
think there might be a broad appeal for this I'll be happy to make a pull
request for it.

Thanks,
Jeff


On Mon, Jun 26, 2017 at 6:13 PM, Jeff Zemerick  wrote:

> Thanks everyone! I will make a JIRA task and look over the shared links.
>
> Jeff
>
>
> On Mon, Jun 26, 2017 at 2:57 PM, Bryan Rosander 
> wrote:
>
>> +1
>>
>> It looks like winsw would be a good option.  I noticed it also supports
>> arbitrary executables, not just Java programs.  That would mean we could
>> use it for both C++ and Java implementations unless there's a good reason
>> not to (once C++ version can run on Windows).
>>
>> On Mon, Jun 26, 2017 at 2:45 PM, Joey Frazee 
>> wrote:
>>
>> > Jefff, there was a related thread about this a few months back:
>> > https://lists.apache.org/thread.html/05abafa804b0bb774211ef602d5fc2
>> > ec3aa8bdf5c584f2aab3014b42@%3Cdev.nifi.apache.org%3E <
>> > https://lists.apache.org/thread.html/05abafa804b0bb774211ef602d5fc2
>> > ec3aa8bdf5c584f2aab3014b42@%3Cdev.nifi.apache.org%3E>
>> >
>> > In that, Andre suggested an approach using https://github.com/kohsuke/
>> > winsw  and maybe he has a branch
>> > already, but anything with a compatible license will certainly be a
>> great
>> > contribution.
>> >
>> > I’m sure me and him, and others are very interested in this.
>> >
>> > -joey
>> >
>> > > On Jun 26, 2017, at 1:17 PM, Aldrin Piri 
>> wrote:
>> > >
>> > > Hi Jeff,
>> > >
>> > > A PR would most certainly be welcomed and (likely could be an easy win
>> > for
>> > > NiFi as well).  The only caveat to be mindful of is that any
>> > > frameworks/tools/utilities should be friendly with ALv2 terms as per
>> > > http://www.apache.org/legal/resolved.html.   If you have any
>> particular
>> > > items in mind and are unsure, please feel free to follow up on here
>> and
>> > we
>> > > can work though what licensing looks like.
>> > >
>> > > On Mon, Jun 26, 2017 at 2:12 PM, Jeff Zemerick 
>> > wrote:
>> > >
>> > >> Hi,
>> > >>
>> > >> I see a ticket to make the C++ version run as a Windows service
>> > >> (MINIFI-89). Is there a recommended method of running the Java
>> version
>> > as a
>> > >> Windows service? If not, would there be any interest in a pull
>> request
>> > to
>> > >> add that functionality?
>> > >>
>> > >> Thanks,
>> > >> Jeff
>> > >>
>> >
>> >
>>
>
>

Re: RTC clarification

[Joey Frazee]

Joe(s), as you mentioned, even if we have a non-committer review, it can’t be 
merged until a committer decides whether to accept whatever decision was 
provided. So, the burden is still on committers as to whether it’s really a +1 
or not. And presumably this should only happen if there’s some evidence that 
the right things happened.

So, I think the big question is how much to encourage non-committers to review. 
And, I think there’s probably more to gain from trying to be very encouraging 
than not. It builds community, it can be a teaching moment, and it can offload 
work where there isn’t enough time or expertise.

This would be really easy if the project required a double +1 to merge because 
there wouldn’t be any confusion about whether any one reviewer had sole 
authority, but I think if the developer guide and README was very encouraging 
and very explicit about how non-committer reviews would be treated, it’ll be 
easy to roll with.

On Jul 7, 2017, 9:10 AM -0500, Joe Witt , wrote:
> We're looking at a possible set of scenarios comprised of a
> 'submitter' and a 'reviewer'. There can be one or more reviewers. A
> submitter or reviewer is either a committer or is not a committer. If
> there is at least one reviewer that is a committer it is a committer
> reviewed scenario. So with that in mind...
>
> A) Committer submitted, Non-Committer reviewed = This can be merged in
> the event of a positive review outcome.
>
> B) Committer submitted, Committer reviewed = This can be merged in the
> event of a positive review outcome.
>
> C) Non-Committer submitted, Non-Committer reviewed = This cannot be
> merged until there is at least one positive committer review.
> However, that review is made easier for the committer as someone who
> is still building merit in the community has already done work here
> and further this is a great chance to work with/grow those folks in
> the community.
>
> D) Non-committer submitted, Committer reviewed = This can be merged in
> the event of a positive review outcome.
>
> Scenario B and D is easy and probably there is no discussion needed.
> Same for scenario C as there has to be at least one committer involved
> for the code to get pushed in the first place. I suspect it is only
> scenario A where we have some 'yeah but...' sort of thoughts going on.
>
> I am favorable to us allowing scenario A to result in a merge because
> at the end of the day there is a committer involved, heavily involved
> in fact, and they've already been voted by the community to be a
> committer. That is a high bar as it should be.
>
> The risk of bad commits getting through needs to be balanced against
> the risk of community growth being hampered by slow review cycles.
> Let's be honest, we need the help with review bandwidth. It is really
> hard to keep up and to my mind one of the best ways to annoy/deter
> contributors from advancing is to make the time between contribution
> to feedback take a long time.
>
>
> On Fri, Jul 7, 2017 at 9:58 AM, Joe Skora  wrote:
> > I agree that non-committer review make more sense if the reviewer has
> > established some level of credibility and involvement in the community.
> >
> > Ultimately, the final committer has to be a community member and they will
> > have final responsibility for the code being Apache compliant and NiFi
> > ready, so even reviews by less well known members of the community should
> > still be low risk.
> >
> > On Fri, Jul 7, 2017 at 9:24 AM, Bryan Bende  wrote:
> >
> > > I agree with encouraging reviews from everyone, but I lean towards
> > > "binding" reviews coming from committers.
> > >
> > > If we allow any review to be binding, there could be completely
> > > different levels of review that occur...
> > >
> > > There could be someone who isn't a committer yet, but has been
> > > contributing already and will probably do a very thorough review of
> > > someone's contribution, and there could be someone else who we never
> > > interacted with us before and writes "+1 LGTM" on a PR and we have no
> > > idea if they know what they are talking about or if they even tried
> > > the contribution to see if it works. Obviously a committer can also
> > > write "+1 LGTM", but I think when that comes from a committer it holds
> > > more weight.
> > >
> > > I think we may also want to clarify if we are only talking about
> > > "submitted by committer, reviewed by non-committer" or also talking
> > > about "submitted by non-committer, reviewed by non-committer".
> > >
> > > For the first case I can see the argument that since the contribution
> > > is from a committer who is already trusted, they can make the right
> > > judgement call based on the review. Where as in the second case, just
> > > because a community member submitted something and another community
> > > member says it looks good, doesn't necessarily mean a committer should
> > > come along and automatically merge it 

Re: [DRAFT][REPORT] Apache NiFi - July 2017

[Joe Witt]

thanks team.  board report submitted.

On Fri, Jul 7, 2017 at 10:05 AM, Yolanda Davis
 wrote:
> +1 LGTM
>
> On Fri, Jul 7, 2017 at 8:10 AM, Marc  wrote:
>
>> +1 Looks good!
>>
>> On Fri, Jul 7, 2017 at 7:43 AM, Andrew Psaltis 
>> wrote:
>>
>> > +1
>> >
>> > On Thu, Jul 6, 2017 at 08:20 Pierre Villard > >
>> > wrote:
>> >
>> > > +1
>> > >
>> > > 2017-07-06 14:09 GMT+02:00 Joe Skora :
>> > >
>> > > > +1  Release this package as NiFi Board Report July 2017
>> > > >
>> > > > On Thu, Jul 6, 2017 at 7:46 AM, Tony Kurc  wrote:
>> > > >
>> > > > > I don't have any concerns, looks good!
>> > > > >
>> > > > > On Thu, Jul 6, 2017 at 2:01 AM, Aldrin Piri 
>> > > > wrote:
>> > > > >
>> > > > > > Looks good.  Thanks for compiling this, Joe.
>> > > > > >
>> > > > > > On Tue, Jul 4, 2017 at 9:50 AM, Joe Witt 
>> > wrote:
>> > > > > >
>> > > > > > > Team,
>> > > > > > >
>> > > > > > > It's that time again to submit our board report for Apache
>> NiFi.
>> > > > > > > Please see below draft.  If you have any suggestions/fixes,
>> edits
>> > > > > > > please advise.
>> > > > > > >
>> > > > > > > I'll submit the report in a few days.
>> > > > > > >
>> > > > > > > Thanks
>> > > > > > > Joe
>> > > > > > >
>> > > > > > > +_+_+_+_+_+_+_
>> > > > > > >
>> > > > > > > ## 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.
>> > > > > > >
>> > > > > > > ## Issues:
>> > > > > > >  - There are no issues requiring board attention at this time.
>> > > > > > >
>> > > > > > > ## Activity:
>> > > > > > >  - Based on board feedback in last report the descriptions
>> above
>> > > have
>> > > > > > been
>> > > > > > >simplified to avoid confusing child/subproject terminology.
>> > We
>> > > > have
>> > > > > > >successfully conducted and completed name searches for the
>> > > MiNiFi
>> > > > > and
>> > > > > > >Registry efforts.
>> > > > > > >  - Conducted numerous releases as listed below.  The 0.7.x
>> > releases
>> > > > > > focused
>> > > > > > >on providing simple bug fixes and resolving reported CVEs.
>> > The
>> > > > 1.x
>> > > > > > >releases brought about stability, performance improvements,
>> > and
>> > > > > > > addressed
>> > > > > > >reported CVEs.  Further, in the 1.x releases numerous
>> > > substantive
>> > > > > > > features
>> > > > > > >were introduced including the ability to run multiple
>> versions
>> > > of
>> > > > > the
>> > > > > > > same
>> > > > > > >components and support for both format and schema aware
>> record
>> > > > > > > processors
>> > > > > > >to easily handle cases like acquisition, SQL based routing,
>> > > > > > enrichment,
>> > > > > > >conversion, and delivery of record oriented data.  These
>> make
>> > > many
>> > > > > > > common
>> > > > > > >record oriented use cases far more performant, intuitive,
>> and
>> > > > retain
>> > > > > > the
>> > > > > > >full power of NiFi's provenance features.
>> > > > > > >
>> > > > > > > ## Health report:
>> > > > > > >  - Health of the community is strong and indicators of strength
>> > > > > continue
>> > > > > > >trending in the right direction. Mailing list and JIRA
>> > activity
>> > > is
>> > > > > > > strong.
>> > > > > > >ASF Hipchat is serving as an on-ramp for new users to our
>> > > mailing
>> > > > > list
>> > > > > > > and
>> > > > > > >JIRA systems. We continue to see new users and contributors.
>> > The
>> > > > PMC
>> > > > > > and
>> > > > > > >committer ranks grew again during this reporting cycle and
>> the
>> > > > > > pipeline
>> > > > > > >is encouraging. We're generating many releases with new
>> > release
>> > > > > > managers
>> > > > > > >stepping up often. The team handles security reports swiftly
>> > and
>> > > > > > follows
>> > > > > > >ASF security team published processes effectively.
>> > > > > > >
>> > > > > > > ## PMC changes:
>> > > > > > >
>> > > > > > >  - Currently 22 PMC members.
>> > > > > > >  - New PMC members:
>> > > > > > > - Koji Kawamura was added to the PMC on Fri May 26 2017
>> > > > > > > - Pierre Villard 

Re: Interest in a time series simulator processor for NiFi

[Matt Burgess]

Chris,

This sounds great! IMO Realistic data generation in all forms is a great 
addition, looking forward to your contribution!

Regards,
Matt


> On Jul 7, 2017, at 10:18 AM, Chris Herrera  wrote:
> 
> Hi All,
> 
> I am trying to gauge interest in a processor I have written that generates 
> realistic time series data. I used the excellent GenerateFlowFile processor 
> for a long time for load testing, etc..., however, I needed something that 
> mirrored more the semantics of a sensor, and more importantly generated data 
> like one. I have wrapped another Apache 2 licensed project TSimulus[1] that 
> generates realistic time series data driven by a JSON configuration file. The 
> idea is that this can be used to simulate a more IoT-like scenario. More than 
> anything I am just trying to see if this is something that has value outside 
> of my little world.
> 
> Regards,
> Chris 
> 
> [1] - https://github.com/cetic/TSimulus

Interest in a time series simulator processor for NiFi

[Chris Herrera]

Hi All,

I am trying to gauge interest in a processor I have written that generates 
realistic time series data. I used the excellent GenerateFlowFile processor for 
a long time for load testing, etc..., however, I needed something that mirrored 
more the semantics of a sensor, and more importantly generated data like one. I 
have wrapped another Apache 2 licensed project TSimulus[1] that generates 
realistic time series data driven by a JSON configuration file. The idea is 
that this can be used to simulate a more IoT-like scenario. More than anything 
I am just trying to see if this is something that has value outside of my 
little world.

Regards,
Chris 

[1] - https://github.com/cetic/TSimulus

Re: RTC clarification

[Joe Witt]

We're looking at a possible set of scenarios comprised of a
'submitter' and a 'reviewer'.  There can be one or more reviewers.  A
submitter or reviewer is either a committer or is not a committer. If
there is at least one reviewer that is a committer it is a committer
reviewed scenario.  So with that in mind...

A) Committer submitted, Non-Committer reviewed = This can be merged in
the event of a positive review outcome.

B) Committer submitted, Committer reviewed = This can be merged in the
event of a positive review outcome.

C) Non-Committer submitted, Non-Committer reviewed = This cannot be
merged until there is at least one positive committer review.
However, that review is made easier for the committer as someone who
is still building merit in the community has already done work here
and further this is a great chance to work with/grow those folks in
the community.

D) Non-committer submitted, Committer reviewed = This can be merged in
the event of a positive review outcome.

Scenario B and D is easy and probably there is no discussion needed.
Same for scenario C as there has to be at least one committer involved
for the code to get pushed in the first place.  I suspect it is only
scenario A where we have some 'yeah but...' sort of thoughts going on.

I am favorable to us allowing scenario A to result in a merge because
at the end of the day there is a committer involved, heavily involved
in fact, and they've already been voted by the community to be a
committer.  That is a high bar as it should be.

The risk of bad commits getting through needs to be balanced against
the risk of community growth being hampered by slow review cycles.
Let's be honest, we need the help with review bandwidth.  It is really
hard to keep up and to my mind one of the best ways to annoy/deter
contributors from advancing is to make the time between contribution
to feedback take a long time.


On Fri, Jul 7, 2017 at 9:58 AM, Joe Skora  wrote:
> I agree that non-committer review make more sense if the reviewer has
> established some level of credibility and involvement in the community.
>
> Ultimately, the final committer has to be a community member and they will
> have final responsibility for the code being Apache compliant and NiFi
> ready, so even reviews by less well known members of the community should
> still be low risk.
>
> On Fri, Jul 7, 2017 at 9:24 AM, Bryan Bende  wrote:
>
>> I agree with encouraging reviews from everyone, but I lean towards
>> "binding" reviews coming from committers.
>>
>> If we allow any review to be binding, there could be completely
>> different levels of review that occur...
>>
>> There could be someone who isn't a committer yet, but has been
>> contributing already and will probably do a very thorough review of
>> someone's contribution, and there could be someone else who we never
>> interacted with us before and writes "+1 LGTM" on a PR and we have no
>> idea if they know what they are talking about or if they even tried
>> the contribution to see if it works. Obviously a committer can also
>> write "+1 LGTM", but I think when that comes from a committer it holds
>> more weight.
>>
>> I think we may also want to clarify if we are only talking about
>> "submitted by committer, reviewed by non-committer" or also talking
>> about "submitted by non-committer, reviewed by non-committer".
>>
>> For the first case I can see the argument that since the contribution
>> is from a committer who is already trusted, they can make the right
>> judgement call based on the review. Where as in the second case, just
>> because a community member submitted something and another community
>> member says it looks good, doesn't necessarily mean a committer should
>> come along and automatically merge it in.
>>
>>
>> On Fri, Jul 7, 2017 at 4:13 AM, Michael Hogue
>>  wrote:
>> > Thanks for fielding the question, Tony.
>> >
>> > Joe and James' statements both make sense. I suppose a case by case
>> > analysis could be carried out, too. For example, since I'm mostly
>> > unfamiliar with the code base but am looking to gain familiarity, I'm
>> > reviewing pretty straightforward or trivial PRs. My plan was to continue
>> > doing that until I felt comfortable reviewing something with a larger
>> > impact, such as the new TCPListenRecord processor implementation [1].
>> > However, as Tony explained, my original question was whether that sort of
>> > review would be binding or whether I should be doing it at all. I think
>> > both of those questions were answered here in that ultimately committer
>> > sign off is needed, but reviews may be binding regardless of source.
>> >
>> > Thanks for the feedback!
>> >
>> > Mike
>> >
>> >
>> > [1] https://github.com/apache/nifi/pull/1987
>> > On Fri, Jul 7, 2017 at 01:14 James Wing  wrote:
>> >
>> >> We should definitely encourage review feedback from non-committers.
>> >> Getting additional 

Re: [DRAFT][REPORT] Apache NiFi - July 2017

[Yolanda Davis]

+1 LGTM

On Fri, Jul 7, 2017 at 8:10 AM, Marc  wrote:

> +1 Looks good!
>
> On Fri, Jul 7, 2017 at 7:43 AM, Andrew Psaltis 
> wrote:
>
> > +1
> >
> > On Thu, Jul 6, 2017 at 08:20 Pierre Villard  >
> > wrote:
> >
> > > +1
> > >
> > > 2017-07-06 14:09 GMT+02:00 Joe Skora :
> > >
> > > > +1  Release this package as NiFi Board Report July 2017
> > > >
> > > > On Thu, Jul 6, 2017 at 7:46 AM, Tony Kurc  wrote:
> > > >
> > > > > I don't have any concerns, looks good!
> > > > >
> > > > > On Thu, Jul 6, 2017 at 2:01 AM, Aldrin Piri 
> > > > wrote:
> > > > >
> > > > > > Looks good.  Thanks for compiling this, Joe.
> > > > > >
> > > > > > On Tue, Jul 4, 2017 at 9:50 AM, Joe Witt 
> > wrote:
> > > > > >
> > > > > > > Team,
> > > > > > >
> > > > > > > It's that time again to submit our board report for Apache
> NiFi.
> > > > > > > Please see below draft.  If you have any suggestions/fixes,
> edits
> > > > > > > please advise.
> > > > > > >
> > > > > > > I'll submit the report in a few days.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Joe
> > > > > > >
> > > > > > > +_+_+_+_+_+_+_
> > > > > > >
> > > > > > > ## 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.
> > > > > > >
> > > > > > > ## Issues:
> > > > > > >  - There are no issues requiring board attention at this time.
> > > > > > >
> > > > > > > ## Activity:
> > > > > > >  - Based on board feedback in last report the descriptions
> above
> > > have
> > > > > > been
> > > > > > >simplified to avoid confusing child/subproject terminology.
> > We
> > > > have
> > > > > > >successfully conducted and completed name searches for the
> > > MiNiFi
> > > > > and
> > > > > > >Registry efforts.
> > > > > > >  - Conducted numerous releases as listed below.  The 0.7.x
> > releases
> > > > > > focused
> > > > > > >on providing simple bug fixes and resolving reported CVEs.
> > The
> > > > 1.x
> > > > > > >releases brought about stability, performance improvements,
> > and
> > > > > > > addressed
> > > > > > >reported CVEs.  Further, in the 1.x releases numerous
> > > substantive
> > > > > > > features
> > > > > > >were introduced including the ability to run multiple
> versions
> > > of
> > > > > the
> > > > > > > same
> > > > > > >components and support for both format and schema aware
> record
> > > > > > > processors
> > > > > > >to easily handle cases like acquisition, SQL based routing,
> > > > > > enrichment,
> > > > > > >conversion, and delivery of record oriented data.  These
> make
> > > many
> > > > > > > common
> > > > > > >record oriented use cases far more performant, intuitive,
> and
> > > > retain
> > > > > > the
> > > > > > >full power of NiFi's provenance features.
> > > > > > >
> > > > > > > ## Health report:
> > > > > > >  - Health of the community is strong and indicators of strength
> > > > > continue
> > > > > > >trending in the right direction. Mailing list and JIRA
> > activity
> > > is
> > > > > > > strong.
> > > > > > >ASF Hipchat is serving as an on-ramp for new users to our
> > > mailing
> > > > > list
> > > > > > > and
> > > > > > >JIRA systems. We continue to see new users and contributors.
> > The
> > > > PMC
> > > > > > and
> > > > > > >committer ranks grew again during this reporting cycle and
> the
> > > > > > pipeline
> > > > > > >is encouraging. We're generating many releases with new
> > release
> > > > > > managers
> > > > > > >stepping up often. The team handles security reports swiftly
> > and
> > > > > > follows
> > > > > > >ASF security team published processes effectively.
> > > > > > >
> > > > > > > ## PMC changes:
> > > > > > >
> > > > > > >  - Currently 22 PMC members.
> > > > > > >  - New PMC members:
> > > > > > > - Koji Kawamura was added to the PMC on Fri May 26 2017
> > > > > > > - Pierre Villard was added to the PMC on Sun May 21 2017
> > > > > > > - Yolanda Davis was added to the PMC on Wed May 17 2017
> > > > > > >
> > > > > > > ## Committer base changes:
> > > > > > >
> > > > > > >  - Currently 34 committers.
> > > > > > >  - New commmitters:
> > > > > > > 

Re: RTC clarification

[Joe Skora]

I agree that non-committer review make more sense if the reviewer has
established some level of credibility and involvement in the community.

Ultimately, the final committer has to be a community member and they will
have final responsibility for the code being Apache compliant and NiFi
ready, so even reviews by less well known members of the community should
still be low risk.

On Fri, Jul 7, 2017 at 9:24 AM, Bryan Bende  wrote:

> I agree with encouraging reviews from everyone, but I lean towards
> "binding" reviews coming from committers.
>
> If we allow any review to be binding, there could be completely
> different levels of review that occur...
>
> There could be someone who isn't a committer yet, but has been
> contributing already and will probably do a very thorough review of
> someone's contribution, and there could be someone else who we never
> interacted with us before and writes "+1 LGTM" on a PR and we have no
> idea if they know what they are talking about or if they even tried
> the contribution to see if it works. Obviously a committer can also
> write "+1 LGTM", but I think when that comes from a committer it holds
> more weight.
>
> I think we may also want to clarify if we are only talking about
> "submitted by committer, reviewed by non-committer" or also talking
> about "submitted by non-committer, reviewed by non-committer".
>
> For the first case I can see the argument that since the contribution
> is from a committer who is already trusted, they can make the right
> judgement call based on the review. Where as in the second case, just
> because a community member submitted something and another community
> member says it looks good, doesn't necessarily mean a committer should
> come along and automatically merge it in.
>
>
> On Fri, Jul 7, 2017 at 4:13 AM, Michael Hogue
>  wrote:
> > Thanks for fielding the question, Tony.
> >
> > Joe and James' statements both make sense. I suppose a case by case
> > analysis could be carried out, too. For example, since I'm mostly
> > unfamiliar with the code base but am looking to gain familiarity, I'm
> > reviewing pretty straightforward or trivial PRs. My plan was to continue
> > doing that until I felt comfortable reviewing something with a larger
> > impact, such as the new TCPListenRecord processor implementation [1].
> > However, as Tony explained, my original question was whether that sort of
> > review would be binding or whether I should be doing it at all. I think
> > both of those questions were answered here in that ultimately committer
> > sign off is needed, but reviews may be binding regardless of source.
> >
> > Thanks for the feedback!
> >
> > Mike
> >
> >
> > [1] https://github.com/apache/nifi/pull/1987
> > On Fri, Jul 7, 2017 at 01:14 James Wing  wrote:
> >
> >> We should definitely encourage review feedback from non-committers.
> >> Getting additional perspectives, interest, and enthusiasm from users is
> >> critical for any project, doubly so for an integrating application where
> >> committers cannot be experts in all the systems we are integrating
> with.  I
> >> believe NiFi could use more review bandwidth.  Are missing out on
> potential
> >> reviewers because of the current policy?
> >>
> >> I do not have any experience with non-committer "binding reviews" as
> >> described in the Apache Gossip thread.  How would that work?  Wouldn't a
> >> committer have to review the review and decide to commit?  If we knew
> the
> >> reviewer well enough to accept their judgement, why not make them a
> >> committer?
> >>
> >> My expectation is that many non-committer reviews are helpful and
> >> constructive, but not necessarily 100% comprehensive.  Reviewers might
> >> comment on the JIRA ticket without working with the PR, or try the
> proposed
> >> change without reviewing the code, tests, etc.  All great stuff, but
> >> backstopped by committers.
> >>
> >> Thanks,
> >>
> >> James
> >>
> >> On Thu, Jul 6, 2017 at 7:30 PM, Joe Witt  wrote:
> >>
> >> > It is undefined at this point and I agree we should reach consensus
> >> > and document it.
> >> >
> >> > I am in favor making non-committer reviews binding.
> >> >
> >> > Why do we do RTC:
> >> > - To help bring along new committers/grow the community
> >> > - To help promote quality by having peer reviews
> >> >
> >> > Enabling non-committer reviews to be binding still allows both of
> >> > those to be true.
> >> >
> >> > On Thu, Jul 6, 2017 at 10:10 PM, Tony Kurc  wrote:
> >> > > All, I was having a discussion with Mike Hogue - a recent
> contributor -
> >> > off
> >> > > list, and he had some questions about the review process. And
> largely
> >> the
> >> > > root of the question was, if a non-committer reviews a patch or PR
> >> (which
> >> > > Mike has spent some time doing), is that considered a "review"? I
> >> didn't
> >> > > have the answers, so I went on a hunt for 

Re: RTC clarification

[Brandon DeVries]

There are always exceptions, but I think the best way to ensure that the
spirit of what we're going for is being followed is to say "no one commits
their own code".  While additional eyes are never going to be a bad thing,
requiring a second person to "sign off" on and then commit the code would
seem to help keep the writing and reviewing steps separate, as we want them
to be.

Secondarily, with no judgement attached to the statement, a review from
someone who's learning the code base might not have the same depth of
understanding and awareness of context as a review from someone with more
experience on the project.  I would think for a review to be trusted, we
would need a certain level of trust in the reviewer... and the best current
process we have for that is committer status.  Like James said, "If we knew
the reviewer well enough to accept their judgement, why not make them a
committer?"

Brandon

On Fri, Jul 7, 2017 at 9:24 AM Bryan Bende  wrote:

> I agree with encouraging reviews from everyone, but I lean towards
> "binding" reviews coming from committers.
>
> If we allow any review to be binding, there could be completely
> different levels of review that occur...
>
> There could be someone who isn't a committer yet, but has been
> contributing already and will probably do a very thorough review of
> someone's contribution, and there could be someone else who we never
> interacted with us before and writes "+1 LGTM" on a PR and we have no
> idea if they know what they are talking about or if they even tried
> the contribution to see if it works. Obviously a committer can also
> write "+1 LGTM", but I think when that comes from a committer it holds
> more weight.
>
> I think we may also want to clarify if we are only talking about
> "submitted by committer, reviewed by non-committer" or also talking
> about "submitted by non-committer, reviewed by non-committer".
>
> For the first case I can see the argument that since the contribution
> is from a committer who is already trusted, they can make the right
> judgement call based on the review. Where as in the second case, just
> because a community member submitted something and another community
> member says it looks good, doesn't necessarily mean a committer should
> come along and automatically merge it in.
>
>
> On Fri, Jul 7, 2017 at 4:13 AM, Michael Hogue
>  wrote:
> > Thanks for fielding the question, Tony.
> >
> > Joe and James' statements both make sense. I suppose a case by case
> > analysis could be carried out, too. For example, since I'm mostly
> > unfamiliar with the code base but am looking to gain familiarity, I'm
> > reviewing pretty straightforward or trivial PRs. My plan was to continue
> > doing that until I felt comfortable reviewing something with a larger
> > impact, such as the new TCPListenRecord processor implementation [1].
> > However, as Tony explained, my original question was whether that sort of
> > review would be binding or whether I should be doing it at all. I think
> > both of those questions were answered here in that ultimately committer
> > sign off is needed, but reviews may be binding regardless of source.
> >
> > Thanks for the feedback!
> >
> > Mike
> >
> >
> > [1] https://github.com/apache/nifi/pull/1987
> > On Fri, Jul 7, 2017 at 01:14 James Wing  wrote:
> >
> >> We should definitely encourage review feedback from non-committers.
> >> Getting additional perspectives, interest, and enthusiasm from users is
> >> critical for any project, doubly so for an integrating application where
> >> committers cannot be experts in all the systems we are integrating
> with.  I
> >> believe NiFi could use more review bandwidth.  Are missing out on
> potential
> >> reviewers because of the current policy?
> >>
> >> I do not have any experience with non-committer "binding reviews" as
> >> described in the Apache Gossip thread.  How would that work?  Wouldn't a
> >> committer have to review the review and decide to commit?  If we knew
> the
> >> reviewer well enough to accept their judgement, why not make them a
> >> committer?
> >>
> >> My expectation is that many non-committer reviews are helpful and
> >> constructive, but not necessarily 100% comprehensive.  Reviewers might
> >> comment on the JIRA ticket without working with the PR, or try the
> proposed
> >> change without reviewing the code, tests, etc.  All great stuff, but
> >> backstopped by committers.
> >>
> >> Thanks,
> >>
> >> James
> >>
> >> On Thu, Jul 6, 2017 at 7:30 PM, Joe Witt  wrote:
> >>
> >> > It is undefined at this point and I agree we should reach consensus
> >> > and document it.
> >> >
> >> > I am in favor making non-committer reviews binding.
> >> >
> >> > Why do we do RTC:
> >> > - To help bring along new committers/grow the community
> >> > - To help promote quality by having peer reviews
> >> >
> >> > Enabling non-committer reviews to be binding still 

Re: RTC clarification

[Bryan Bende]

I agree with encouraging reviews from everyone, but I lean towards
"binding" reviews coming from committers.

If we allow any review to be binding, there could be completely
different levels of review that occur...

There could be someone who isn't a committer yet, but has been
contributing already and will probably do a very thorough review of
someone's contribution, and there could be someone else who we never
interacted with us before and writes "+1 LGTM" on a PR and we have no
idea if they know what they are talking about or if they even tried
the contribution to see if it works. Obviously a committer can also
write "+1 LGTM", but I think when that comes from a committer it holds
more weight.

I think we may also want to clarify if we are only talking about
"submitted by committer, reviewed by non-committer" or also talking
about "submitted by non-committer, reviewed by non-committer".

For the first case I can see the argument that since the contribution
is from a committer who is already trusted, they can make the right
judgement call based on the review. Where as in the second case, just
because a community member submitted something and another community
member says it looks good, doesn't necessarily mean a committer should
come along and automatically merge it in.


On Fri, Jul 7, 2017 at 4:13 AM, Michael Hogue
 wrote:
> Thanks for fielding the question, Tony.
>
> Joe and James' statements both make sense. I suppose a case by case
> analysis could be carried out, too. For example, since I'm mostly
> unfamiliar with the code base but am looking to gain familiarity, I'm
> reviewing pretty straightforward or trivial PRs. My plan was to continue
> doing that until I felt comfortable reviewing something with a larger
> impact, such as the new TCPListenRecord processor implementation [1].
> However, as Tony explained, my original question was whether that sort of
> review would be binding or whether I should be doing it at all. I think
> both of those questions were answered here in that ultimately committer
> sign off is needed, but reviews may be binding regardless of source.
>
> Thanks for the feedback!
>
> Mike
>
>
> [1] https://github.com/apache/nifi/pull/1987
> On Fri, Jul 7, 2017 at 01:14 James Wing  wrote:
>
>> We should definitely encourage review feedback from non-committers.
>> Getting additional perspectives, interest, and enthusiasm from users is
>> critical for any project, doubly so for an integrating application where
>> committers cannot be experts in all the systems we are integrating with.  I
>> believe NiFi could use more review bandwidth.  Are missing out on potential
>> reviewers because of the current policy?
>>
>> I do not have any experience with non-committer "binding reviews" as
>> described in the Apache Gossip thread.  How would that work?  Wouldn't a
>> committer have to review the review and decide to commit?  If we knew the
>> reviewer well enough to accept their judgement, why not make them a
>> committer?
>>
>> My expectation is that many non-committer reviews are helpful and
>> constructive, but not necessarily 100% comprehensive.  Reviewers might
>> comment on the JIRA ticket without working with the PR, or try the proposed
>> change without reviewing the code, tests, etc.  All great stuff, but
>> backstopped by committers.
>>
>> Thanks,
>>
>> James
>>
>> On Thu, Jul 6, 2017 at 7:30 PM, Joe Witt  wrote:
>>
>> > It is undefined at this point and I agree we should reach consensus
>> > and document it.
>> >
>> > I am in favor making non-committer reviews binding.
>> >
>> > Why do we do RTC:
>> > - To help bring along new committers/grow the community
>> > - To help promote quality by having peer reviews
>> >
>> > Enabling non-committer reviews to be binding still allows both of
>> > those to be true.
>> >
>> > On Thu, Jul 6, 2017 at 10:10 PM, Tony Kurc  wrote:
>> > > All, I was having a discussion with Mike Hogue - a recent contributor -
>> > off
>> > > list, and he had some questions about the review process. And largely
>> the
>> > > root of the question was, if a non-committer reviews a patch or PR
>> (which
>> > > Mike has spent some time doing), is that considered a "review"? I
>> didn't
>> > > have the answers, so I went on a hunt for documentation. I started with
>> > the
>> > > Contributor Guide [1]. The guide describes reviewing, and calls out a
>> > > Reviewer role, but doesn't specifically point out that Reviewer is a
>> > > committer, just that a committer "can actively promote contributions
>> into
>> > > the repository", and goes on to imply the non-committers can review.
>> > >
>> > > Given this, I was unable to answer this question:
>> > > If a committer "X" submits a patch or PR, it is reviewed by a
>> > non-committer
>> > > "Y", does that review satisfy the RTC requirement, and "X" may merge in
>> > the
>> > > patch?
>> > >
>> > > I found a related discussion on the 

Re: [DRAFT][REPORT] Apache NiFi - July 2017

[Matt Burgess]

+1 LGTM, thank you for putting this together!

Regards,
Matt

On Tue, Jul 4, 2017 at 11:50 AM, Joe Witt  wrote:
> Team,
>
> It's that time again to submit our board report for Apache NiFi.
> Please see below draft.  If you have any suggestions/fixes, edits
> please advise.
>
> I'll submit the report in a few days.
>
> Thanks
> Joe
>
> +_+_+_+_+_+_+_
>
> ## 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.
>
> ## Issues:
>  - There are no issues requiring board attention at this time.
>
> ## Activity:
>  - Based on board feedback in last report the descriptions above have been
>simplified to avoid confusing child/subproject terminology.  We have
>successfully conducted and completed name searches for the MiNiFi and
>Registry efforts.
>  - Conducted numerous releases as listed below.  The 0.7.x releases focused
>on providing simple bug fixes and resolving reported CVEs.  The 1.x
>releases brought about stability, performance improvements, and addressed
>reported CVEs.  Further, in the 1.x releases numerous substantive features
>were introduced including the ability to run multiple versions of the same
>components and support for both format and schema aware record processors
>to easily handle cases like acquisition, SQL based routing, enrichment,
>conversion, and delivery of record oriented data.  These make many common
>record oriented use cases far more performant, intuitive, and retain the
>full power of NiFi's provenance features.
>
> ## Health report:
>  - Health of the community is strong and indicators of strength continue
>trending in the right direction. Mailing list and JIRA activity is strong.
>ASF Hipchat is serving as an on-ramp for new users to our mailing list and
>JIRA systems. We continue to see new users and contributors. The PMC and
>committer ranks grew again during this reporting cycle and the pipeline
>is encouraging. We're generating many releases with new release managers
>stepping up often. The team handles security reports swiftly and follows
>ASF security team published processes effectively.
>
> ## PMC changes:
>
>  - Currently 22 PMC members.
>  - New PMC members:
> - Koji Kawamura was added to the PMC on Fri May 26 2017
> - Pierre Villard was added to the PMC on Sun May 21 2017
> - Yolanda Davis was added to the PMC on Wed May 17 2017
>
> ## Committer base changes:
>
>  - Currently 34 committers.
>  - New commmitters:
> - Marc Parisi was added as a committer on Thu Jun 01 2017
> - Andrew M. Lim was added as a committer on Wed May 31 2017
>
> ## Releases:
>
>  - Apache NiFi 1.3.0 was released June 9 2017.
>  - Apache NiFi 0.7.4 was released June 9 2017.
>  - Apache NiFi MiNiFi (java) 0.2.0 was released May 19 2017.
>  - Apache NiFi 0.7.3 was released May 19 2017.
>  - Apache NiFi MiNiFi (cpp) 0.2.0 was released May 14 2017.
>  - Apache NiFi 1.2.0 was released May 10 2017.
>
> ## Mailing list activity:
>
>  - Activity on the mailing lists remains extremely 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.
>
>  - us...@nifi.apache.org:
> - 512 subscribers (up 39 in the last 3 months):
> - 936 emails sent to list (846 in previous quarter)
>
>  - dev@nifi.apache.org:
> - 367 subscribers (up 24 in the last 3 months):
> - 1018 emails sent to list (925 in previous quarter)
>
>  - iss...@nifi.apache.org:
> - 42 subscribers (up 4 in the last 3 months):
> - 7936 emails sent to list (6592 in previous quarter)
>
>
> ## JIRA activity:
>
>  - 573 JIRA tickets created in the last 3 months
>  - 421 JIRA tickets closed/resolved in the last 3 months

Re: [DRAFT][REPORT] Apache NiFi - July 2017

[Marc]

+1 Looks good!

On Fri, Jul 7, 2017 at 7:43 AM, Andrew Psaltis 
wrote:

> +1
>
> On Thu, Jul 6, 2017 at 08:20 Pierre Villard 
> wrote:
>
> > +1
> >
> > 2017-07-06 14:09 GMT+02:00 Joe Skora :
> >
> > > +1  Release this package as NiFi Board Report July 2017
> > >
> > > On Thu, Jul 6, 2017 at 7:46 AM, Tony Kurc  wrote:
> > >
> > > > I don't have any concerns, looks good!
> > > >
> > > > On Thu, Jul 6, 2017 at 2:01 AM, Aldrin Piri 
> > > wrote:
> > > >
> > > > > Looks good.  Thanks for compiling this, Joe.
> > > > >
> > > > > On Tue, Jul 4, 2017 at 9:50 AM, Joe Witt 
> wrote:
> > > > >
> > > > > > Team,
> > > > > >
> > > > > > It's that time again to submit our board report for Apache NiFi.
> > > > > > Please see below draft.  If you have any suggestions/fixes, edits
> > > > > > please advise.
> > > > > >
> > > > > > I'll submit the report in a few days.
> > > > > >
> > > > > > Thanks
> > > > > > Joe
> > > > > >
> > > > > > +_+_+_+_+_+_+_
> > > > > >
> > > > > > ## 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.
> > > > > >
> > > > > > ## Issues:
> > > > > >  - There are no issues requiring board attention at this time.
> > > > > >
> > > > > > ## Activity:
> > > > > >  - Based on board feedback in last report the descriptions above
> > have
> > > > > been
> > > > > >simplified to avoid confusing child/subproject terminology.
> We
> > > have
> > > > > >successfully conducted and completed name searches for the
> > MiNiFi
> > > > and
> > > > > >Registry efforts.
> > > > > >  - Conducted numerous releases as listed below.  The 0.7.x
> releases
> > > > > focused
> > > > > >on providing simple bug fixes and resolving reported CVEs.
> The
> > > 1.x
> > > > > >releases brought about stability, performance improvements,
> and
> > > > > > addressed
> > > > > >reported CVEs.  Further, in the 1.x releases numerous
> > substantive
> > > > > > features
> > > > > >were introduced including the ability to run multiple versions
> > of
> > > > the
> > > > > > same
> > > > > >components and support for both format and schema aware record
> > > > > > processors
> > > > > >to easily handle cases like acquisition, SQL based routing,
> > > > > enrichment,
> > > > > >conversion, and delivery of record oriented data.  These make
> > many
> > > > > > common
> > > > > >record oriented use cases far more performant, intuitive, and
> > > retain
> > > > > the
> > > > > >full power of NiFi's provenance features.
> > > > > >
> > > > > > ## Health report:
> > > > > >  - Health of the community is strong and indicators of strength
> > > > continue
> > > > > >trending in the right direction. Mailing list and JIRA
> activity
> > is
> > > > > > strong.
> > > > > >ASF Hipchat is serving as an on-ramp for new users to our
> > mailing
> > > > list
> > > > > > and
> > > > > >JIRA systems. We continue to see new users and contributors.
> The
> > > PMC
> > > > > and
> > > > > >committer ranks grew again during this reporting cycle and the
> > > > > pipeline
> > > > > >is encouraging. We're generating many releases with new
> release
> > > > > managers
> > > > > >stepping up often. The team handles security reports swiftly
> and
> > > > > follows
> > > > > >ASF security team published processes effectively.
> > > > > >
> > > > > > ## PMC changes:
> > > > > >
> > > > > >  - Currently 22 PMC members.
> > > > > >  - New PMC members:
> > > > > > - Koji Kawamura was added to the PMC on Fri May 26 2017
> > > > > > - Pierre Villard was added to the PMC on Sun May 21 2017
> > > > > > - Yolanda Davis was added to the PMC on Wed May 17 2017
> > > > > >
> > > > > > ## Committer base changes:
> > > > > >
> > > > > >  - Currently 34 committers.
> > > > > >  - New commmitters:
> > > > > > - Marc Parisi was added as a committer on Thu Jun 01 2017
> > > > > > - Andrew M. Lim was added as a committer on Wed May 31 2017
> > > > > >
> > > > > > ## Releases:
> > > > > >
> > > > > >  - Apache NiFi 1.3.0 was released June 9 2017.
> > > > > >  - Apache NiFi 0.7.4 was released June 9 2017.
> > > > > >  - Apache NiFi MiNiFi (java) 0.2.0 was released May 19 

Re: [DRAFT][REPORT] Apache NiFi - July 2017

[Andrew Psaltis]

+1

On Thu, Jul 6, 2017 at 08:20 Pierre Villard 
wrote:

> +1
>
> 2017-07-06 14:09 GMT+02:00 Joe Skora :
>
> > +1  Release this package as NiFi Board Report July 2017
> >
> > On Thu, Jul 6, 2017 at 7:46 AM, Tony Kurc  wrote:
> >
> > > I don't have any concerns, looks good!
> > >
> > > On Thu, Jul 6, 2017 at 2:01 AM, Aldrin Piri 
> > wrote:
> > >
> > > > Looks good.  Thanks for compiling this, Joe.
> > > >
> > > > On Tue, Jul 4, 2017 at 9:50 AM, Joe Witt  wrote:
> > > >
> > > > > Team,
> > > > >
> > > > > It's that time again to submit our board report for Apache NiFi.
> > > > > Please see below draft.  If you have any suggestions/fixes, edits
> > > > > please advise.
> > > > >
> > > > > I'll submit the report in a few days.
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > +_+_+_+_+_+_+_
> > > > >
> > > > > ## 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.
> > > > >
> > > > > ## Issues:
> > > > >  - There are no issues requiring board attention at this time.
> > > > >
> > > > > ## Activity:
> > > > >  - Based on board feedback in last report the descriptions above
> have
> > > > been
> > > > >simplified to avoid confusing child/subproject terminology.  We
> > have
> > > > >successfully conducted and completed name searches for the
> MiNiFi
> > > and
> > > > >Registry efforts.
> > > > >  - Conducted numerous releases as listed below.  The 0.7.x releases
> > > > focused
> > > > >on providing simple bug fixes and resolving reported CVEs.  The
> > 1.x
> > > > >releases brought about stability, performance improvements, and
> > > > > addressed
> > > > >reported CVEs.  Further, in the 1.x releases numerous
> substantive
> > > > > features
> > > > >were introduced including the ability to run multiple versions
> of
> > > the
> > > > > same
> > > > >components and support for both format and schema aware record
> > > > > processors
> > > > >to easily handle cases like acquisition, SQL based routing,
> > > > enrichment,
> > > > >conversion, and delivery of record oriented data.  These make
> many
> > > > > common
> > > > >record oriented use cases far more performant, intuitive, and
> > retain
> > > > the
> > > > >full power of NiFi's provenance features.
> > > > >
> > > > > ## Health report:
> > > > >  - Health of the community is strong and indicators of strength
> > > continue
> > > > >trending in the right direction. Mailing list and JIRA activity
> is
> > > > > strong.
> > > > >ASF Hipchat is serving as an on-ramp for new users to our
> mailing
> > > list
> > > > > and
> > > > >JIRA systems. We continue to see new users and contributors. The
> > PMC
> > > > and
> > > > >committer ranks grew again during this reporting cycle and the
> > > > pipeline
> > > > >is encouraging. We're generating many releases with new release
> > > > managers
> > > > >stepping up often. The team handles security reports swiftly and
> > > > follows
> > > > >ASF security team published processes effectively.
> > > > >
> > > > > ## PMC changes:
> > > > >
> > > > >  - Currently 22 PMC members.
> > > > >  - New PMC members:
> > > > > - Koji Kawamura was added to the PMC on Fri May 26 2017
> > > > > - Pierre Villard was added to the PMC on Sun May 21 2017
> > > > > - Yolanda Davis was added to the PMC on Wed May 17 2017
> > > > >
> > > > > ## Committer base changes:
> > > > >
> > > > >  - Currently 34 committers.
> > > > >  - New commmitters:
> > > > > - Marc Parisi was added as a committer on Thu Jun 01 2017
> > > > > - Andrew M. Lim was added as a committer on Wed May 31 2017
> > > > >
> > > > > ## Releases:
> > > > >
> > > > >  - Apache NiFi 1.3.0 was released June 9 2017.
> > > > >  - Apache NiFi 0.7.4 was released June 9 2017.
> > > > >  - Apache NiFi MiNiFi (java) 0.2.0 was released May 19 2017.
> > > > >  - Apache NiFi 0.7.3 was released May 19 2017.
> > > > >  - Apache NiFi MiNiFi (cpp) 0.2.0 was released May 14 2017.
> > > > >  - Apache NiFi 1.2.0 was released May 10 2017.
> > > > >
> > > > > ## Mailing list activity:
> > > > >
> > > > >  - Activity on the mailing lists remains extremely high with a
> > mixture
> > > > >of new users, contributors, and deeper 

Re: RTC clarification

[Michael Hogue]

Thanks for fielding the question, Tony.

Joe and James' statements both make sense. I suppose a case by case
analysis could be carried out, too. For example, since I'm mostly
unfamiliar with the code base but am looking to gain familiarity, I'm
reviewing pretty straightforward or trivial PRs. My plan was to continue
doing that until I felt comfortable reviewing something with a larger
impact, such as the new TCPListenRecord processor implementation [1].
However, as Tony explained, my original question was whether that sort of
review would be binding or whether I should be doing it at all. I think
both of those questions were answered here in that ultimately committer
sign off is needed, but reviews may be binding regardless of source.

Thanks for the feedback!

Mike


[1] https://github.com/apache/nifi/pull/1987
On Fri, Jul 7, 2017 at 01:14 James Wing  wrote:

> We should definitely encourage review feedback from non-committers.
> Getting additional perspectives, interest, and enthusiasm from users is
> critical for any project, doubly so for an integrating application where
> committers cannot be experts in all the systems we are integrating with.  I
> believe NiFi could use more review bandwidth.  Are missing out on potential
> reviewers because of the current policy?
>
> I do not have any experience with non-committer "binding reviews" as
> described in the Apache Gossip thread.  How would that work?  Wouldn't a
> committer have to review the review and decide to commit?  If we knew the
> reviewer well enough to accept their judgement, why not make them a
> committer?
>
> My expectation is that many non-committer reviews are helpful and
> constructive, but not necessarily 100% comprehensive.  Reviewers might
> comment on the JIRA ticket without working with the PR, or try the proposed
> change without reviewing the code, tests, etc.  All great stuff, but
> backstopped by committers.
>
> Thanks,
>
> James
>
> On Thu, Jul 6, 2017 at 7:30 PM, Joe Witt  wrote:
>
> > It is undefined at this point and I agree we should reach consensus
> > and document it.
> >
> > I am in favor making non-committer reviews binding.
> >
> > Why do we do RTC:
> > - To help bring along new committers/grow the community
> > - To help promote quality by having peer reviews
> >
> > Enabling non-committer reviews to be binding still allows both of
> > those to be true.
> >
> > On Thu, Jul 6, 2017 at 10:10 PM, Tony Kurc  wrote:
> > > All, I was having a discussion with Mike Hogue - a recent contributor -
> > off
> > > list, and he had some questions about the review process. And largely
> the
> > > root of the question was, if a non-committer reviews a patch or PR
> (which
> > > Mike has spent some time doing), is that considered a "review"? I
> didn't
> > > have the answers, so I went on a hunt for documentation. I started with
> > the
> > > Contributor Guide [1]. The guide describes reviewing, and calls out a
> > > Reviewer role, but doesn't specifically point out that Reviewer is a
> > > committer, just that a committer "can actively promote contributions
> into
> > > the repository", and goes on to imply the non-committers can review.
> > >
> > > Given this, I was unable to answer this question:
> > > If a committer "X" submits a patch or PR, it is reviewed by a
> > non-committer
> > > "Y", does that review satisfy the RTC requirement, and "X" may merge in
> > the
> > > patch?
> > >
> > > I found a related discussion on the email list in March [2], which I
> > think
> > > implies at least some of the community assumed the canonical review
> must
> > be
> > > by a committer. I also went back a bit to early days [3], where Benson
> > > implied a much less "formal" review process.
> > >
> > > What I'm hoping for is hopefully come to a consensus of what our
> project
> > > expectations are and document in the Contributor Guide. My expectation
> > was
> > > that non-committers could review, similar to what Sean discussed on
> this
> > > thread for Apache Gossip (incubating) [4]. However, I don't believe
> this
> > is
> > > the current consensus.
> > >
> > > Thoughts?
> > >
> > > Tony
> > >
> > > 1.
> > > https://cwiki.apache.org/confluence/display/NIFI/Contributor
> > +Guide#ContributorGuide-CodeReviewProcess
> > > 2.
> > > https://mail-archives.apache.org/mod_mbox/nifi-dev/201703.mb
> > ox/%3CCALJK9a7onOKo%3DXtAEmL7PSBUEBEqOOhcT9WSz-RZaNxqV6q%
> > 3Dmg%40mail.gmail.com%3E
> > > 3.
> > > https://mail-archives.apache.org/mod_mbox/nifi-dev/201501.mb
> > ox/%3CCALhtWkf67UpOe9W9HQ3RSn00xb_=C6ZMxN+_SEfWthpQrU5fsg@
> > mail.gmail.com%3E
> > > 4.
> > > http://mail-archives.apache.org/mod_mbox/incubator-gossip-de
> > v/201606.mbox/%3CCAN5cbe6P8aEEOLMA%2BPrfpQg9c_AWeSfvvmom8jAp%3Dk7wUpoVgQ%
> > 40mail.gmail.com%3E
> >
>