+1, binding * Verified the downloads worked * Verified the signature (and that Bryan used SHA-512 for the underlying digest algorithm) * Verified checksums * Verified the Maven build worked and the RAT check passed * Verified the presence of valid LICENSE, NOTICE, and README files * Verified the git commit ID was correct * Verified the RC was branched off the correct git commit ID * Verified the RC binary contained valid LICENSE, NOTICE, and README files * Verified the registry application worked as expected (standalone) * Verified the NiFi PR 2219 built with the registry already installed * Verified the integration between the two applications worked as expected * Verified changes to a process group propagated to the registry and to cloned/imported process groups on the canvas * Verified error message and that changes are not lost if committed when registry is unavailable
Notes: * A couple minor formatting/whitespace issues in the root pom.xml * “No results match this query” is an off-putting message for the default. Before a user has created a bucket (no indicator from the default listing that one must go to settings to do so), there are obviously no results, but the user does not expect that they have executed a “query” (unless they are a DBA, probably). Can we change this to be “Go to Settings to add your first bucket” if count(buckets) == 0? * After adding a bucket, I would expect “NiFi Registry/All” to show that bucket, not “No results match this query”. A user has to click the dropdown on “All” to see the new bucket listed. * Once entering the new bucket, the message displayed is still “No results match this query”. At this point, a new user has no idea what type of object would be a result at this level. Again, if the logic "count(flow) == 0”, I think a different message should be displayed like “Add versioned flows to this bucket from NiFi”. * I believe this is echoing Pierre, but I think the status icons in the PG and the toolbar need alt texts (both for 508 compliance and for people unfamiliar with the meaning of the icons). * If following the instructions provided in the release helper email, the local changes made to the first process group must be “Committed locally” in order for the imported PG to contain them. Otherwise, the imported PG will only contain the empty PG, while any changes made in the original are only in the originally and in a “locally modified” state. * When a PG is imported and an existing PG has the same name, the new PG should have the name “[Existing name] copy” or similar to indicate which is the original/source. * If a versioned PG is imported and is not at the most current version, local changes cannot be committed. Rather, “Change Version” and “Stop version control” are the only two options available. If a version upgrade is attempted, an error occurs and the local changes must be reverted. At this time, “Show local changes” and “Revert local changes” are made available in the version menu (not the error dialog). If these changes are non-conflicting, why does this occur? If this cannot be reconciled in the same flow snippet versioning chain, I suggest branching here and allowing it to be saved separately (i.e. provenance chain forking or git branching). Or at least warn the user on the first change made if the PG is not at the most recent version because a significant amount of work can be put in and then either lost or the ability to upgrade/save is lost with no user knowledge. * If the local changes are reverted, the menu options and state remain the same (conflicted) until a manual refresh occurs. * If changes are made to the cloned PG and committed, the changes are reflected in the registry UI and the original PG can be changed to that version, but it does not show the “a new version is available” indicator icon or notify the user that new changes are available (even after manual refresh). Despite all these notes, I think this is an excellent first release and will make NiFi much more useful for many users and open the possibilities for continued development that has been prevented up to this point. Thanks to everyone who worked on this. Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Dec 29, 2017, at 2:56 PM, Yolanda Davis <[email protected]> wrote: > > +1, binding > > Have been looking forward to this contribution; it is a great addition to > the community! > > Following the release helper I verified signatures, hashes as well as > the README, > NOTICE, and LICENSE. Successfully built the project per instructions and > built the NiFi project using the referenced PR. From there I tested in > unsecured mode the basic test suggested in the helper guide. Also tried > minor things such as deleting a flow from registry that was associated to a > PG to ensure NiFi updated as expected. > > One thing that would be helpful is additional documentation on the NiFi > side on how to integrate with Registry. I also noticed on my test to delete > a flow where it seemed there was a pretty big lag when NiFi recognized the > change, even beyond my attempt to refresh. Not sure if this is > configurable or just odd behavior on my end. > > Another minor issue is when someone adds a process group, enters a name for > it and then selects import to use a flow in registry. The name gets > overwritten by the flow (which makes sense) but wondering if there's a way > to either allow user to keep new name or at least let them know it will be > overwritten by version in registry? > > Again great job! > > -yolanda > > > > On Thu, Dec 28, 2017 at 1:09 PM, Bryan Bende <[email protected]> wrote: > >> Hello, >> >> I am pleased to be calling this vote for the source release of Apache >> NiFi Registry 0.1.0. >> >> The source zip, including signatures, digests, etc. can be found at: >> https://repository.apache.org/content/repositories/orgapachenifi-1115/ >> >> The Git tag is nifi-registry-0.1.0-RC1 >> The Git commit ID is 81b99e7b04491eabb72ddf30754053ca12d0fcca >> https://git-wip-us.apache.org/repos/asf?p=nifi-registry.git;a=commit;h= >> 81b99e7b04491eabb72ddf30754053ca12d0fcca >> >> Checksums of nifi-registry-0.1.0-source-release.zip: >> MD5: 56244c3c296cdc9c3fcc6d22590b80d1 >> SHA1: 6354e91f868f40d6656ec2467bde307260ad63ca >> SHA256: 2c680e441e6c4bfa2381bf004e9b19a6a79401a6a83e04597d0a714a95efd301 >> >> Release artifacts are signed with the following key: >> https://people.apache.org/keys/committer/bbende.asc >> >> KEYS file available here: >> https://dist.apache.org/repos/dist/release/nifi/KEYS >> >> 65 issues were closed/resolved for this release: >> https://issues.apache.org/jira/secure/ReleaseNote.jspa? >> projectId=12320920&version=12340217 >> >> Release note highlights can be found here: >> https://cwiki.apache.org/confluence/display/NIFI/ >> Release+Notes#ReleaseNotes-NiFiRegistry0.1.0 >> >> The vote will be open for 96 hours. >> >> Please download the release candidate and evaluate the necessary items >> including checking hashes, signatures, build from source, and test. >> >> The please vote: >> >> [ ] +1 Release this package as nifi-registry-0.1.0 >> [ ] +0 no opinion >> [ ] -1 Do not release this package because... >> > > > > -- > -- > [email protected] > @YolandaMDavis
signature.asc
Description: Message signed with OpenPGP using GPGMail
