Re: Apache NiFi MiNiFi 0.5.0 RC2 Release Helper Guide

[Andrew Psaltis]

Sorry for the goof on response thread.

Andy,
Thanks for the key education, greatly appreciated.

On Tue, Jul 3, 2018 at 02:10 Andy LoPresto  wrote:

> Hi Andrew,
>
> A couple things:
>
> * You accidentally replied to the release helper guide; I think you meant
> to vote on the [VOTE] thread
> * the warning message you received during GPG verification simply means
> that you had not previously marked Jeremy’s key as “trusted” via your GPG
> application. The intended process is:
>
> * Jeremy posts his public key on a key server
> * You verify Jeremy’s key via a different channel (chat/in-person/voice
> verification) — this is where the key fingerprint is useful; he can read it
> over the phone and you, knowing his voice, can verify that he is using the
> key ostensibly published by him
> * If you do not know Jeremy or cannot contact him, you can delegate that
> trust verification to someone else. For example, I have verified the key
> fingerprint with Jeremy offline, so I trust that this key is his. I have
> signed that public key using my private key (key ID 0x2F7DEF69) and I can
> publish that signature to public key servers. Now, if you trust my key, you
> can accept that transitive trust as well. (The servers are under stress
> right now but this link should show that when the server is up:
> https://pgp.mit.edu/pks/lookup?search=0x6B295AD5&op=index).
> * Once you have verified or trust that the key represents Jeremy, you can
> assign it a level of “owner trust” in your GPG application, ranging from
> Never -> Marginal -> Full, representing how seriously you believe this is
> Jeremy’s key.
> * After a trust level has been assigned, you will not get the message you
> did. You will get a message like the one below:
>
> hw12203:/Users/alopresto/Workspace/scratch/release_verification/minifi-java-0.5.0
> (master) alopresto
> 🔓 0s @ 11:09:55 $ gpg --verify -v minifi-0.5.0-source-release.zip.asc
> gpg: assuming signed data in 'minifi-0.5.0-source-release.zip'
> gpg: Signature made Thu Jun 28 09:31:10 2018 PDT
> gpg:using RSA key 50AA60AD5D58311187B0BEB5C6E550DA6B295AD5
> gpg:issuer "jeremyd...@apache.org"
> gpg: using pgp trust model
> gpg: Good signature from "Jeremy Dyer (CODE SIGNING KEY) <
> jeremyd...@apache.org>" [full]
> gpg: binary signature, digest algorithm SHA512, key algorithm rsa4096
>
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 1, 2018, at 8:35 PM, Andrew Psaltis 
> wrote:
>
> +1 (non-binding)
>
> - verified keys
> - verified signatures
> - verified README's, NOTICE and LICENSE
> - tested c2 NiFiRestConfigurationProvider with NiFi 1.6.0 and minifi from
> this build, various changes to template -- bumping versions, etc.
>
> One thing I noticed when verifying the keys, which I am not sure is an
> issue is the WARNING that the key is not certified with a trusted
> signature. The following is the output from the command:
>
> gpg: assuming signed data in 'minifi-0.5.0-source-release.zip'
> gpg: Signature made Fri Jun 29 00:31:10 2018 +08
> gpg:using RSA key 50AA60AD5D58311187B0BEB5C6E550DA6B295AD5
> gpg:issuer "jeremyd...@apache.org"
> gpg: Good signature from "Jeremy Dyer (CODE SIGNING KEY) <
> jeremyd...@apache.org>" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 50AA 60AD 5D58 3111 87B0  BEB5 C6E5 50DA 6B29 5AD5
>
>
> On Fri, Jun 29, 2018 at 1:39 AM Jeremy Dyer  wrote:
>
> Hello Apache NiFi community,
>
> Please find the associated guidance to help those interested in
> validating/verifying the release so they can vote.
>
> # Download latest KEYS file:
>  https://dist.apache.org/repos/dist/dev/nifi/KEYS
>
> # Import keys file:
>  gpg --import KEYS
>
> # [optional] Clear out local maven artifact repository
>
> # Pull down minifi-0.5.0 source release artifacts for review:
>
>  wget
>
>
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip
>  wget
>
>
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.asc
>  wget
>
>
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.sha1
>  wget
>
>
> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.sha256
>
> # Verify the signature
>  gpg --verify minifi-0.5.0-source-release.zip.asc
>
> # Verify the hashes (sha1 and sha256) match the source and what was
> provided in the vote email thread
>  sha1sum minifi-0.5.0-source-release.zip
>  sha256sum minifi-0.5.0-source-release.zip
>
> # Unzip minifi-0.5.0-source-release.zip
>
> # Verify the build works including release audit tool (RAT) checks
>  cd minifi-0.5.0
>  mvn clean install -Pcontrib-check
>
> # Verify the contents contain a good R

Re: validation changes in 1.7.0

[Mike Thomsen]

Mark,

Matt raises a very good point there. Please share the stack traces because
if they follow a general pattern of complaining "it was scoped for this,
but not for that," we can probably get you up and running again very
quickly.

For what it's worth, from my own testing, this is entirely a testing
framework issue. The Mongo bundle was blowing up with all sorts of false
errors during that time, and yet it never seemed to affect the processors
once they were actually running.

On Mon, Jul 2, 2018 at 5:26 PM Matt Burgess  wrote:

> Do your processors work against 1.6.0? I’m wondering if there’s something
> with the new Expression Language scope stuff, I believe that can cause unit
> test failures even if it still works (albeit deprecated) on a live NiFi.
>
> Regards,
> Matt
>
> > On Jul 2, 2018, at 4:52 PM, Mark Payne  wrote:
> >
> > Hey Mark,
> >
> > The validation logic was changed so that instead of performing
> validation on demand each time that
> > the user refreshes stats, navigates to a process group, etc., it all is
> done asynchronously. We then periodically
> > perform validation in the background.
> >
> > So the idea is that we changed when validation is called, not how it is
> called. So I'm not sure why you would have
> > seen customValidate() being called previously but not anymore. It is
> possible that there was previously an implicit
> > call (implicit from the perspective of the unit test, not from the
> perspective of the Test Runner) to validate a
> > component that got removed in some of this refactoring.
> >
> > I do see in StandardProcessorTestRunner (the impl of the TestRunner
> interface) that when run() is called, are still
> > performing validation as we were previously and asserting that the
> processor is valid. It's possible, though, that
> > there is another code path where we now fail to call validate()? Can you
> share any more information about what
> > your unit tests are doing, that previously worked but no longer do?
> >
> > Thanks
> > -Mark
> >
> >
> >> On Jul 2, 2018, at 3:59 PM, Mark Bean  wrote:
> >>
> >> Several of our custom processors are not compatible with version 1.7.0.
> >> There is a growing pattern of unit test failures due to customValidate()
> >> not being executed now where it was being executed in 1.6.0 and prior. I
> >> believe there were changes made in 1.7.0 in terms of how validation -
> and
> >> therefore customValidate() - is performed and/or when it is performed.
> >>
> >> Could someone provide a brief description on how validation was changed
> in
> >> 1.7.0?
> >>
> >> Thanks!
> >> Mark
> >
>

Re: validation changes in 1.7.0

[Matt Burgess]

Do your processors work against 1.6.0? I’m wondering if there’s something with 
the new Expression Language scope stuff, I believe that can cause unit test 
failures even if it still works (albeit deprecated) on a live NiFi.

Regards,
Matt

> On Jul 2, 2018, at 4:52 PM, Mark Payne  wrote:
> 
> Hey Mark,
> 
> The validation logic was changed so that instead of performing validation on 
> demand each time that
> the user refreshes stats, navigates to a process group, etc., it all is done 
> asynchronously. We then periodically
> perform validation in the background.
> 
> So the idea is that we changed when validation is called, not how it is 
> called. So I'm not sure why you would have
> seen customValidate() being called previously but not anymore. It is possible 
> that there was previously an implicit
> call (implicit from the perspective of the unit test, not from the 
> perspective of the Test Runner) to validate a
> component that got removed in some of this refactoring.
> 
> I do see in StandardProcessorTestRunner (the impl of the TestRunner 
> interface) that when run() is called, are still
> performing validation as we were previously and asserting that the processor 
> is valid. It's possible, though, that
> there is another code path where we now fail to call validate()? Can you 
> share any more information about what
> your unit tests are doing, that previously worked but no longer do?
> 
> Thanks
> -Mark
> 
> 
>> On Jul 2, 2018, at 3:59 PM, Mark Bean  wrote:
>> 
>> Several of our custom processors are not compatible with version 1.7.0.
>> There is a growing pattern of unit test failures due to customValidate()
>> not being executed now where it was being executed in 1.6.0 and prior. I
>> believe there were changes made in 1.7.0 in terms of how validation - and
>> therefore customValidate() - is performed and/or when it is performed.
>> 
>> Could someone provide a brief description on how validation was changed in
>> 1.7.0?
>> 
>> Thanks!
>> Mark
> 

Re: validation changes in 1.7.0

[Mark Payne]

Hey Mark,

The validation logic was changed so that instead of performing validation on 
demand each time that
the user refreshes stats, navigates to a process group, etc., it all is done 
asynchronously. We then periodically
perform validation in the background.

So the idea is that we changed when validation is called, not how it is called. 
So I'm not sure why you would have
seen customValidate() being called previously but not anymore. It is possible 
that there was previously an implicit
call (implicit from the perspective of the unit test, not from the perspective 
of the Test Runner) to validate a
component that got removed in some of this refactoring.

I do see in StandardProcessorTestRunner (the impl of the TestRunner interface) 
that when run() is called, are still
performing validation as we were previously and asserting that the processor is 
valid. It's possible, though, that
there is another code path where we now fail to call validate()? Can you share 
any more information about what
your unit tests are doing, that previously worked but no longer do?

Thanks
-Mark


> On Jul 2, 2018, at 3:59 PM, Mark Bean  wrote:
> 
> Several of our custom processors are not compatible with version 1.7.0.
> There is a growing pattern of unit test failures due to customValidate()
> not being executed now where it was being executed in 1.6.0 and prior. I
> believe there were changes made in 1.7.0 in terms of how validation - and
> therefore customValidate() - is performed and/or when it is performed.
> 
> Could someone provide a brief description on how validation was changed in
> 1.7.0?
> 
> Thanks!
> Mark

PR Backlog & review process

[Andy LoPresto]

Hi folks,

Now that we just got a major release out (and NiFi Registry, MiNiFi Java, and 
NiFi FDS releases as well), I wanted to take this opportunity to emphasize the 
strengths that our community brings to the table. We have committers and 
contributors with a wide range of expertise who are able to provide wonderful 
features to the project. I think something that is sometimes difficult with our 
distributed and very busy community is balancing a proper review process with 
bringing down the PR backlog and ensuring we keep the community and development 
active.

As supported by the Powered by NiFi page [1], Twitter, and many presentations 
at conferences around the world, a number of organizations depend on NiFi for 
mission critical uses. While Apache software is provided without warranty, we 
have an obligation to our users to provide the best software possible. The 
infamous Equifax breach was due to an unpatched deployment of Apache Struts [2] 
which had a vulnerability. The resulting media coverage was obviously unkind to 
both entities.

With this in mind, all code reviews must be thorough and to the best of the 
community’s ability. We all bring excellent skills to the table, and this makes 
the community stronger. Doing a simple license check and running the maven 
build to ensure unit tests and contrib-check still pass is not sufficient. Any 
code that comes into the core codebase must now be supported by the community 
at large moving forward. We use a Review-Then-Commit (RTC) process, which is 
different from some other Apache projects. Because of this, our process should 
be proactive and perform extensive testing and evaluation before any code is 
committed. This doesn’t just apply to feature work; NiFi is a large codebase, 
and core refactoring can have serious performance and behavioral interaction 
with other components. There is an ongoing effort to refactor pieces to be more 
interdependent and to adhere to the clearly defined internal framework vs. 
extension points and exposed API.

All of this to say our vibrant community has delivered some incredible features 
and performance improvements, and it is important to continue pushing NiFi to 
be the best project it can be and ensure that we give all of our users the best 
experience possible.


[1] https://nifi.apache.org/powered-by-nifi.html 

[2] https://www.wired.com/story/equifax-breach-no-excuse/

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



signature.asc
Description: Message signed with OpenPGP using GPGMail

validation changes in 1.7.0

[Mark Bean]

Several of our custom processors are not compatible with version 1.7.0.
There is a growing pattern of unit test failures due to customValidate()
not being executed now where it was being executed in 1.6.0 and prior. I
believe there were changes made in 1.7.0 in terms of how validation - and
therefore customValidate() - is performed and/or when it is performed.

Could someone provide a brief description on how validation was changed in
1.7.0?

Thanks!
Mark

Re: Apache NiFi MiNiFi 0.5.0 RC2 Release Helper Guide

[Andy LoPresto]

Hi Andrew,

A couple things:

* You accidentally replied to the release helper guide; I think you meant to 
vote on the [VOTE] thread
* the warning message you received during GPG verification simply means that 
you had not previously marked Jeremy’s key as “trusted” via your GPG 
application. The intended process is:

* Jeremy posts his public key on a key server
* You verify Jeremy’s key via a different channel (chat/in-person/voice 
verification) — this is where the key fingerprint is useful; he can read it 
over the phone and you, knowing his voice, can verify that he is using the key 
ostensibly published by him
* If you do not know Jeremy or cannot contact him, you can delegate that trust 
verification to someone else. For example, I have verified the key fingerprint 
with Jeremy offline, so I trust that this key is his. I have signed that public 
key using my private key (key ID 0x2F7DEF69) and I can publish that signature 
to public key servers. Now, if you trust my key, you can accept that transitive 
trust as well. (The servers are under stress right now but this link should 
show that when the server is up: 
https://pgp.mit.edu/pks/lookup?search=0x6B295AD5&op=index).
* Once you have verified or trust that the key represents Jeremy, you can 
assign it a level of “owner trust” in your GPG application, ranging from Never 
-> Marginal -> Full, representing how seriously you believe this is Jeremy’s 
key.
* After a trust level has been assigned, you will not get the message you did. 
You will get a message like the one below:

hw12203:/Users/alopresto/Workspace/scratch/release_verification/minifi-java-0.5.0
 (master) alopresto
🔓 0s @ 11:09:55 $ gpg --verify -v minifi-0.5.0-source-release.zip.asc
gpg: assuming signed data in 'minifi-0.5.0-source-release.zip'
gpg: Signature made Thu Jun 28 09:31:10 2018 PDT
gpg:using RSA key 50AA60AD5D58311187B0BEB5C6E550DA6B295AD5
gpg:issuer "jeremyd...@apache.org"
gpg: using pgp trust model
gpg: Good signature from "Jeremy Dyer (CODE SIGNING KEY) 
" [full]
gpg: binary signature, digest algorithm SHA512, key algorithm rsa4096


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

> On Jul 1, 2018, at 8:35 PM, Andrew Psaltis  wrote:
> 
> +1 (non-binding)
> 
> - verified keys
> - verified signatures
> - verified README's, NOTICE and LICENSE
> - tested c2 NiFiRestConfigurationProvider with NiFi 1.6.0 and minifi from
> this build, various changes to template -- bumping versions, etc.
> 
> One thing I noticed when verifying the keys, which I am not sure is an
> issue is the WARNING that the key is not certified with a trusted
> signature. The following is the output from the command:
> 
> gpg: assuming signed data in 'minifi-0.5.0-source-release.zip'
> gpg: Signature made Fri Jun 29 00:31:10 2018 +08
> gpg:using RSA key 50AA60AD5D58311187B0BEB5C6E550DA6B295AD5
> gpg:issuer "jeremyd...@apache.org"
> gpg: Good signature from "Jeremy Dyer (CODE SIGNING KEY) <
> jeremyd...@apache.org>" [unknown]
> gpg: WARNING: This key is not certified with a trusted signature!
> gpg:  There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: 50AA 60AD 5D58 3111 87B0  BEB5 C6E5 50DA 6B29 5AD5
> 
> 
> On Fri, Jun 29, 2018 at 1:39 AM Jeremy Dyer  wrote:
> 
>> Hello Apache NiFi community,
>> 
>> Please find the associated guidance to help those interested in
>> validating/verifying the release so they can vote.
>> 
>> # Download latest KEYS file:
>>  https://dist.apache.org/repos/dist/dev/nifi/KEYS
>> 
>> # Import keys file:
>>  gpg --import KEYS
>> 
>> # [optional] Clear out local maven artifact repository
>> 
>> # Pull down minifi-0.5.0 source release artifacts for review:
>> 
>>  wget
>> 
>> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip
>>  wget
>> 
>> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.asc
>>  wget
>> 
>> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.sha1
>>  wget
>> 
>> https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi/0.5.0/minifi-0.5.0-source-release.zip.sha256
>> 
>> # Verify the signature
>>  gpg --verify minifi-0.5.0-source-release.zip.asc
>> 
>> # Verify the hashes (sha1 and sha256) match the source and what was
>> provided in the vote email thread
>>  sha1sum minifi-0.5.0-source-release.zip
>>  sha256sum minifi-0.5.0-source-release.zip
>> 
>> # Unzip minifi-0.5.0-source-release.zip
>> 
>> # Verify the build works including release audit tool (RAT) checks
>>  cd minifi-0.5.0
>>  mvn clean install -Pcontrib-check
>> 
>> # Verify the contents contain a good README, NOTICE, and LICENSE.
>> 
>> # Verify the git commit ID is correct
>> 
>> # Verify the RC was branched off the correct git commit ID
>> 
>> 
>> There are three convenience binaries gener

[RESULT][VOTE] Release Apache NiFi MiNiFi 0.5.0 RC2

[Jeremy Dyer]

Apache NiFi Community,

I am pleased to announce that the 0.5.0 release of Apache NiFi MiNiFi
passes with
  7 +1 (binding) votes
  0 -1 (binding) votes
  2 +1 (non-binding) votes
  0 -1 (non-binding) votes

Thanks to all who helped make this release possible.

Here is the PMC vote thread:
https://lists.apache.org/thread.html/0d6a82bfc420a5d7739881a55db8eaed848e09e3ca618e7bb8118fa4@%3Cdev.nifi.apache.org%3E

Re: [VOTE] Release Apache NiFi MiNiFi 0.5.0 RC2

[Pierre Villard]

+1, binding

Went through the release helper guide, ran a simple test with NiFi and C2
instance, all looks good to me.
Thanks to the community for this release and thanks Jeremy for taking care
of the RM duties.

Pierre

2018-07-01 20:54 GMT+02:00 Kevin Doran :

> +1, non-binding.
>
> Followed the steps in the release helper guide, verified the readme, ran a
> simple flow with s2s.
>
> Nice work everyone! Thanks for RM'ing this one Jeremy.
>
> Kevin
>
> On 7/1/18, 14:22, "Tony Kurc"  wrote:
>
> +1 (binding)
>
> License + notice look good
> built without issue
> hashes and signature look good
> Tested using a really simple flow
>
> On Sun, Jul 1, 2018 at 1:42 PM, Jeff  wrote:
>
> > +1, binding
> >
> > Ran through the release helper guide
> > Created a simple flow for MiNiFi in NiFi, used the transform of the
> MiNiFi
> > toolkit to create a config.yml
> > Started MiNiFi with the config.yml created by the MiNiFi toolkit
> > Observed the results in NiFi, working as expected.
> >
> > On Fri, Jun 29, 2018 at 6:59 PM Andy LoPresto 
> > wrote:
> >
> > > +1, binding
> > >
> > > Verified all keys and checksums, ran through all the builds,
> verified
> > > tests and contrib-check, and the existence of
> LICENSE/NOTICE/README at
> > > appropriate locations. A couple minor points on the release
> process below
> > > (and some other non-blocking issues that I will open as Jiras).
> > >
> > > * Now that MD5 is deprecated, I believe we agreed to provide a
> SHA-512
> > > signature as well. The release guide should be updated to include
> this
> > for
> > > next time.
> > > * The release helper should specify that LICENSE, NOTICE, and
> README are
> > > in minifi-assembly/target*/minifi-0.5.0-bin/minifi-0.5.0/*
> > >
> > > Andy LoPresto
> > > alopre...@apache.org
> > > *alopresto.apa...@gmail.com *
> > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > >
> > > On Jun 29, 2018, at 8:29 AM, Aldrin Piri 
> wrote:
> > >
> > > Hi folks,
> > >
> > > I worked with Jeremy to resolve the discrepancy and we were able
> to get
> > the
> > > commits/tag in question from the Maven release plugin pushed to
> the repo.
> > >
> > > The minifi-0.5.0-RC2 tag is correct in pointing to the source of
> the...
> > > source commit 58b8c598c0866c8f1200164ab14f3df0d632d522 which was
> > initiated
> > > from the last commit on master, 05f516d3da33a0547ccfad34241450
> > 4cdacd4a68.
> > >
> > > Links for reference:
> > > tag:
> > > * https://github.com/apache/nifi-minifi/tree/minifi-0.5.0-RC2
> > > *
> > >
> > > https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=
> > shortlog;h=refs/tags/minifi-0.5.0-RC2
> > >
> > > RC2 branch commit:
> > > *
> > >
> > > https://github.com/apiri/nifi-minifi/commit/
> > 58b8c598c0866c8f1200164ab14f3df0d632d522
> > > *
> > >
> > > https://git-wip-us.apache.org/repos/asf?p=nifi-minifi.git;a=
> commit;h=
> > 58b8c598c0866c8f1200164ab14f3df0d632d522
> > >
> > > --aldrin
> > >
> > >
> > > On Fri, Jun 29, 2018 at 7:59 AM Jeff Zemerick <
> jzemer...@apache.org>
> > > wrote:
> > >
> > > +1 non-binding
> > >
> > > Built and ran MiNiFi and C2 without issues.
> > >
> > > On Thu, Jun 28, 2018 at 3:59 PM Aldrin Piri 
> wrote:
> > >
> > > +1, binding
> > >
> > > comments:
> > > My vote is on the assumption there there was a slight mix up with
> tagging
> > > and it can be easily remedied.  The
> > > 05f516d3da33a0547ccfad342414504cdacd4a68
> > > points to the last commit and a snapshot version.  This is correct
> from
> > > where the release is started but does not capture the generated
> prepared
> > > release artifacts.  I believe if that is pushed and referenced, we
> will
> > > have what is packed in the source distribution, which is listed as
> 0.5.0,
> > > non-snapshot.
> > >
> > > signature and hashes looked good
> > > verified contrib, build, and tests of minifi, config-toolkit, and
> c2
> > >
> > > server
> > >
> > > verified transform functionality of config toolkit
> > > verified consumption of transformed config in minifi and its
> successful
> > > site to site transaction to nifi
> > > verified interaction with c2 server with a file based provider
> > >
> > > On Thu, Jun 28, 2018 at 1:19 PM Jeremy Dyer  >
> > >
> > > wrote:
> > >
> > >
> > > Hello,
> > >
> > > I am pleased to call this vote for the source release of Apache
> NiFi
> > >
> > > MiNiFi
> > >
> > > minifi-0.5.0 RC2.
> > >
> > > The source zip, including signatures, digests, etc. can be found
> at:
> > > *
> > >
> > > https://repository.apache.org/content/re