Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt <jo...@gmail.com>]

Team,

Another update on efforts to close-in on the NiFi 1.2.0 release.
We're below 20 JIRAs now and there has been good momentum.  A couple
items still need work but look really important and then there is
review traction/feedback cycles.  Will just keep monitoring it and
actively defending to close the loop on 1.2.0 until we're there.

Thanks
Joe

On Tue, Mar 28, 2017 at 9:45 AM, Joe Witt <jo...@gmail.com> wrote:
> Team,
>
> Status of JIRA cleanup toward an Apache NiFi 1.2.0 release candidate
> which Mr Bende has so wonderfully volunteered to RM:
>
> There are 20 open JIRAs as of now.
>
> 12 of 20 have PRs that appear ready/close to ready.
>
> One pattern I noticed quite a bit on the 1.2.0 release is heavy usage
> of 'squatter JIRAs' whereby someone makes a JIRA and with or without
> any review traction and for non blocking issues sets the fix version.
> This practice should be avoided.  The fix version should be reserved
> for once there is a blocker item or there is something with a patch
> contributed and review progress closing in on a merge.
>
> One of them means we need to punt the Twitter processor most likely.
> Don't believe there were new releases to resolve that licensing issue
> by the third party dependency.  I'll take that on.
>   https://issues.apache.org/jira/browse/NIFI-3089
>
> Two of them are build failure issues which means windows and linux
> builds break (highly repeatable):
>   https://issues.apache.org/jira/browse/NIFI-3441
>   https://issues.apache.org/jira/browse/NIFI-3440
>
> A couple need to either be moved out or addressed for implementation
> or review but it isn't clear to me their status:
>   https://issues.apache.org/jira/browse/NIFI-3155
>   https://issues.apache.org/jira/browse/NIFI-1280
>   https://issues.apache.org/jira/browse/NIFI-2656
>   https://issues.apache.org/jira/browse/NIFI-2886
>
> Some are really important and being worked still:
>   https://issues.apache.org/jira/browse/NIFI-3520
>
> Thanks
> Joe
>
> On Wed, Mar 22, 2017 at 9:12 PM, Joe Witt <jo...@gmail.com> wrote:
>> Sweet!  I'll take that deal all day.  Thanks Bryan!
>>
>> On Wed, Mar 22, 2017 at 8:26 PM, Bryan Bende <bb...@gmail.com> wrote:
>>> Joe,
>>>
>>> As of today I believe the PR for NIFI-3380 (component versioning) should
>>> address all of the code review feedback and is in a good place.
>>>
>>> Would like to run through a few more tests tomorrow, and baring any
>>> additional feedback from reviewers, we could possibly merge that tomorrow.
>>> That PR will also bump master to use the newly released NAR plugin.
>>>
>>> Since I got a warm-up with NAR plugin, I don't mind taking on release
>>> manager duties for 1.2, although I would still like help on the JIRA
>>> whipping. I imagine there's still a bit of work to narrow down the
>>> remaining tickets.
>>>
>>> -Bryan
>>>
>>> On Wed, Mar 22, 2017 at 7:35 PM Joe Witt <jo...@gmail.com> wrote:
>>>
>>>> Bryan
>>>>
>>>> How are things looking for what you updated on?  The nar plugin of
>>>> course is out.
>>>>
>>>> We got another question on the user list for 1.2 so I just want to
>>>> make sure we're closing in.  I'll start doing the JIRA whipping.
>>>>
>>>> Thanks
>>>> JOe
>>>>
>>>> On Mon, Mar 13, 2017 at 3:22 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>> > Just a quick update on this discussion...
>>>> >
>>>> > On Friday we were able to post an initial PR for the component
>>>> > versioning work [1].
>>>> >
>>>> > I believe we are ready to move forward with a release of the NAR Maven
>>>> > plugin, there are three tickets to be included in the release [2].
>>>> >
>>>> > If there are no objections, I can take on the release manager duties
>>>> > for the NAR plugin, and can begin to kick off the process tomorrow.
>>>> >
>>>> > -Bryan
>>>> >
>>>> > [1] https://github.com/apache/nifi/pull/1585
>>>> > [2]
>>>> https://issues.apache.org/jira/browse/NIFI-3589?jql=fixVersion%20%3D%20nifi-nar-maven-plugin-1.2.0%20AND%20project%20%3D%20NIFI
>>>> >
>>>> > On Wed, Mar 8, 2017 at 6:19 PM, James Wing <jv...@gmail.com> wrote:
>>>> >> +1 for component versioning in 1.2.0, it will be a solid capstone
>>>> feature.
>>>> >> And I agree it's probably not holding up the release.
>>>> >>
>>>> >> Thanks,
>>>> >>
>>>> >> James
>>>> >>
>>>> >> On Wed, Mar 8, 2017 at 1:21 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>> >>
>>>> >>> James,
>>>> >>>
>>>> >>> No problem :)
>>>> >>>
>>>> >>> I was mostly just suggesting an overall strategy...
>>>> >>>
>>>> >>> Usually when we start closing in on a release we go through the JIRAs
>>>> >>> tagged for that release and try to figure out which ones can be moved
>>>> >>> to a future release, and which ones the community is actually working
>>>> >>> on and close to being ready. Currently we have 39 unresolved JIRAs
>>>> >>> that are tagged as 1.2, one of which is NIFI-3380, and I figured if
>>>> >>> someone looked at the ticket it might look like no work had been done
>>>> >>> and figure that it can just be moved to next release, so I just wanted
>>>> >>> to mention that it is very close to being ready was still hoping for
>>>> >>> it be in 1.2, unless there was strong opinion to move on without it.
>>>> >>> Even if we moved on without it, I believe there is still a bit of work
>>>> >>> to do in that we still need a release manager and we need to decide
>>>> >>> what to do with the 39 JIRAs.
>>>> >>>
>>>> >>> As far as the new NAR plugin and how things will work...
>>>> >>>
>>>> >>> The changes to the NAR plugin add additional information to the
>>>> >>> MANIFEST file in the NAR. Technically existing NiFi would have no
>>>> >>> problem reading the new MANIFEST file because no entries are being
>>>> >>> removed, and the branch I have with the component versioning code for
>>>> >>> NiFi could also run against old NARs that don't have the new entries,
>>>> >>> you just see everything as being "unversioned" and can't actually make
>>>> >>> use of the new capabilities. We'll always have to be able to run older
>>>> >>> NARs because there are tons of custom NARs out there that have not
>>>> >>> been (and may never be) rebuilt with the newer version of the plugin,
>>>> >>> which is fine, they only need to be rebuilt if someone wants to run
>>>> >>> two versions of that NAR at the same time.
>>>> >>>
>>>> >>> Happy to elaborate more on any of the component versioning work if
>>>> >>> anyone is interested.
>>>> >>>
>>>> >>> Thanks,
>>>> >>>
>>>> >>> Bryan
>>>> >>>
>>>> >>>
>>>> >>> On Wed, Mar 8, 2017 at 2:43 PM, Russell Bateman <russ@windofkeltia.com
>>>> >
>>>> >>> wrote:
>>>> >>> > +1 for component versioning in NiFi 1.2!
>>>> >>> >
>>>> >>> >
>>>> >>> > On 03/08/2017 12:40 PM, James Wing wrote:
>>>> >>> >>
>>>> >>> >> Bryan, I'm 100% in favor of you and Matt Gilman doing all the hard
>>>> work.
>>>> >>> >> Oh, and uh... thanks! :)
>>>> >>> >>
>>>> >>> >> So the alternatives are:
>>>> >>> >> a.) Release 1.2.0 sooner (?), but without component versioning
>>>> >>> >> b.) Delay 1.2.0 (?) to incorporate component versioning
>>>> >>> >>
>>>> >>> >> Will the NAR plugin alone commit us to all of the component
>>>> versioning
>>>> >>> >> work
>>>> >>> >> in 1.2, or will the new NAR format be backward-compatible?  Or is
>>>> the
>>>> >>> >> question more about the strategy for 1.2.0?
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> Thanks,
>>>> >>> >>
>>>> >>> >> James
>>>> >>> >>
>>>> >>> >> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bb...@gmail.com>
>>>> wrote:
>>>> >>> >>
>>>> >>> >>> Just wanted to mention that one of the JIRAs tagged for 1.2.0 is
>>>> >>> >>> NIFI-3380 "support multiple versions of the same component" [1] and
>>>> >>> >>> I've been working with Matt Gilman on this [2]. The functionality
>>>> is
>>>> >>> >>> very close to being done and I think we should get this into the
>>>> 1.2.0
>>>> >>> >>> release.
>>>> >>> >>>
>>>> >>> >>> In order to fully leverage the versioned components we will need to
>>>> >>> >>> release an updated Maven NAR plugin, so we would do that first and
>>>> >>> >>> then release 1.2.0 using the new plugin. If everyone is on-board
>>>> with
>>>> >>> >>> this plan then I can advise when we are ready to release the new
>>>> >>> >>> plugin which would be soon.
>>>> >>> >>>
>>>> >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-3380
>>>> >>> >>> [2] https://github.com/bbende/nifi/tree/NIFI-3380
>>>> >>> >>>
>>>> >>> >>> On Fri, Mar 3, 2017 at 9:56 AM, Joe Gresock <jg...@gmail.com>
>>>> >>> wrote:
>>>> >>> >>>>
>>>> >>> >>>> This is good discussion that should continue, but what about the
>>>> >>> >>>> original
>>>> >>> >>>> intent of Joe's post?  "Is there any reason folks can think of to
>>>> hold
>>>> >>> >>>
>>>> >>> >>> off
>>>> >>> >>>>
>>>> >>> >>>> on a 1.2.0 release?"
>>>> >>> >>>>
>>>> >>> >>>> On Fri, Mar 3, 2017 at 1:45 PM, Mark Payne <ma...@hotmail.com>
>>>> >>> wrote:
>>>> >>> >>>>
>>>> >>> >>>>> Andy,
>>>> >>> >>>>>
>>>> >>> >>>>> Sorry, i haven't responded to this thread in over a week, but I
>>>> think
>>>> >>> >>>
>>>> >>> >>> it's
>>>> >>> >>>>>
>>>> >>> >>>>> important to keep going.
>>>> >>> >>>>>
>>>> >>> >>>>> I just clicked "Cancel Patch" on one of my ticket that has a
>>>> patch
>>>> >>> >>>>> available to see which state it returned to.
>>>> >>> >>>>> It did in fact go back to Open. Which I agree is less than ideal.
>>>> >>> >>>>> Though
>>>> >>> >>>>> we could certainly have a process
>>>> >>> >>>>> by which we change the status to "In Progress" after canceling
>>>> the
>>>> >>> >>>
>>>> >>> >>> patch.
>>>> >>> >>>>>
>>>> >>> >>>>> I guess where my viewpoint differs from yours is in the meaning
>>>> of
>>>> >>> "In
>>>> >>> >>>>> Review." Let's say that you submit a
>>>> >>> >>>>> patch for a JIRA. I then review it and find that it needs some
>>>> work -
>>>> >>> >>>>> let's say there's an issue with licensing
>>>> >>> >>>>> not being properly accounted for, for instance. At that point, I
>>>> no
>>>> >>> >>>
>>>> >>> >>> longer
>>>> >>> >>>>>
>>>> >>> >>>>> consider the patch that you provided
>>>> >>> >>>>> to be "In Review." I believe the patch should be canceled, and
>>>> you
>>>> >>> will
>>>> >>> >>>>> need to submit a new patch. I guess
>>>> >>> >>>>> that I view a patch as being an immutable entity.
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>> On Feb 24, 2017, at 7:26 PM, Andy LoPresto <alopresto@apache.org
>>>> >>> >>>
>>>> >>> >>> <mailto:a
>>>> >>> >>>>>
>>>> >>> >>>>> lopresto@apache.org>> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> Mark,
>>>> >>> >>>>>
>>>> >>> >>>>> Your understanding of “Patch Available” certainly makes sense
>>>> and it
>>>> >>> >>>>> explains why you approach the process the way you do. I have a
>>>> >>> slightly
>>>> >>> >>>>> different personal understanding of “Patch Available” — I read
>>>> it to
>>>> >>> >>>
>>>> >>> >>> mean
>>>> >>> >>>>>
>>>> >>> >>>>> “the person responsible for this Jira has contributed code they
>>>> feel
>>>> >>> >>>
>>>> >>> >>> solves
>>>> >>> >>>>>
>>>> >>> >>>>> the issue.” A review will (hopefully) determine if that
>>>> assertion is
>>>> >>> >>>>> correct and complete. I think we kind of agree on "my viewpoint
>>>> is
>>>> >>> >>>
>>>> >>> >>> simply
>>>> >>> >>>>>
>>>> >>> >>>>> that "Patch Available" means "Awaiting Review" or "In Review.””
>>>> but I
>>>> >>> >>>
>>>> >>> >>> see
>>>> >>> >>>>>
>>>> >>> >>>>> “In Review” as a potentially iterative process — it could be on
>>>> the
>>>> >>> >>>
>>>> >>> >>> second
>>>> >>> >>>>>
>>>> >>> >>>>> pass of the contributor responding to comments, but it’s still
>>>> “In
>>>> >>> >>>
>>>> >>> >>> Review”
>>>> >>> >>>>>
>>>> >>> >>>>> in my eyes. I don’t know that the granularity of Jira supports
>>>> the
>>>> >>> >>>
>>>> >>> >>> specific
>>>> >>> >>>>>
>>>> >>> >>>>> workflow states of “been reviewed once but not complete/accepted
>>>> >>> yet”.
>>>> >>> >>>>>
>>>> >>> >>>>> What state does “Cancel Patch” result in? If it just reverts to
>>>> >>> “Open”,
>>>> >>> >>>
>>>> >>> >>> I
>>>> >>> >>>>>
>>>> >>> >>>>> don’t see the value because that obfuscates the difference
>>>> between a
>>>> >>> >>>
>>>> >>> >>> Jira
>>>> >>> >>>>>
>>>> >>> >>>>> that hasn’t even been touched and one that has 90% of the code
>>>> done.
>>>> >>> I
>>>> >>> >>>>> agree we should make the RM’s job easier, but I also think it
>>>> doesn’t
>>>> >>> >>>
>>>> >>> >>> help
>>>> >>> >>>>>
>>>> >>> >>>>> the visibility for reviewers to see a Jira marked as “open” when
>>>> >>> there
>>>> >>> >>>
>>>> >>> >>> is
>>>> >>> >>>>>
>>>> >>> >>>>> the potential for that patch to be ready for merge in a very
>>>> short
>>>> >>> >>>
>>>> >>> >>> amount
>>>> >>> >>>>>
>>>> >>> >>>>> of time.
>>>> >>> >>>>>
>>>> >>> >>>>> I think these conversations will ultimately help us narrow in on
>>>> >>> shared
>>>> >>> >>>>> definitions that make sense to everyone though, so I’m glad we’re
>>>> >>> >>>
>>>> >>> >>> talking
>>>> >>> >>>>>
>>>> >>> >>>>> about it.
>>>> >>> >>>>>
>>>> >>> >>>>> Andy LoPresto
>>>> >>> >>>>> alopresto@apache.org<ma...@apache.org>
>>>> >>> >>>>> alopresto.apache@gmail.com<ma...@gmail.com>
>>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>>>> EF69
>>>> >>> >>>>>
>>>> >>> >>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <markap14@hotmail.com
>>>> >>> <mailto:m
>>>> >>> >>>>> arkap14@hotmail.com>> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> Andy,
>>>> >>> >>>>>
>>>> >>> >>>>> If the reviewer is looking for clarification, then it may make
>>>> sense
>>>> >>> to
>>>> >>> >>>>> leave the JIRA in "Patch Available" state
>>>> >>> >>>>> as you suggest. If there are minor fixes needed, though, then the
>>>> >>> patch
>>>> >>> >>>
>>>> >>> >>> is
>>>> >>> >>>>>
>>>> >>> >>>>> not ready. In JIRA, the verbiage for
>>>> >>> >>>>> Cancel Patch says "The patch is not yet ready to be committed."
>>>> So if
>>>> >>> >>>>> minor fixes are needed, then I believe
>>>> >>> >>>>> it is appropriate to Cancel Patch. Once those changes (minor or
>>>> not)
>>>> >>> >>>>> are
>>>> >>> >>>>> made and the PR updated, then the
>>>> >>> >>>>> PR needs review again and the status should be changed back to
>>>> "Patch
>>>> >>> >>>>> Available" again.
>>>> >>> >>>>>
>>>> >>> >>>>> I guess my viewpoint is simply that "Patch Available" means
>>>> "Awaiting
>>>> >>> >>>>> Review" or "In Review." If it is awaiting
>>>> >>> >>>>> changes of some kind and won't be merged as-is, then we should
>>>> Cancel
>>>> >>> >>>>> Patch.
>>>> >>> >>>>>
>>>> >>> >>>>> Do you or others have differing views on the meaning of "Patch
>>>> >>> >>>
>>>> >>> >>> Available"?
>>>> >>> >>>>>
>>>> >>> >>>>> Thanks
>>>> >>> >>>>> -Mark
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>> On Feb 24, 2017, at 3:27 PM, Andy LoPresto <alopresto@apache.org
>>>> >>> >>>
>>>> >>> >>> <mailto:a
>>>> >>> >>>>>
>>>> >>> >>>>> lopresto@apache.org><ma...@apache.org>> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> Mark,
>>>> >>> >>>>>
>>>> >>> >>>>> I like your point about updating the Jira with the Fix Version
>>>> at the
>>>> >>> >>>
>>>> >>> >>> time
>>>> >>> >>>>>
>>>> >>> >>>>> the PR review begins (or when the PR is submitted, if the
>>>> contributor
>>>> >>> >>>>> is
>>>> >>> >>>>> aware of this process). I think it’s better than waiting for the
>>>> >>> merge,
>>>> >>> >>>
>>>> >>> >>> as
>>>> >>> >>>>>
>>>> >>> >>>>> I proposed before.
>>>> >>> >>>>>
>>>> >>> >>>>> I agree that the reviewer is responsible for keeping the Jira
>>>> updated
>>>> >>> >>>>> in
>>>> >>> >>>>> line with their work. I don’t know if I am on the same page as
>>>> you
>>>> >>> for
>>>> >>> >>>>> “Cancel Patch” if the PR needs changes; sometimes these are minor
>>>> >>> fixes
>>>> >>> >>>
>>>> >>> >>> or
>>>> >>> >>>>>
>>>> >>> >>>>> just looking for clarification from the contributor, and I don’t
>>>> >>> think
>>>> >>> >>>
>>>> >>> >>> that
>>>> >>> >>>>>
>>>> >>> >>>>> warrants canceling the availability of the patch. If they are
>>>> major
>>>> >>> >>>>> architectural changes, then that makes more sense to me.
>>>> >>> >>>>>
>>>> >>> >>>>> Andy LoPresto
>>>> >>> >>>>> alopresto@apache.org<ma...@apache.org><mailto:alo
>>>> >>> >>>>> presto@apache.org>
>>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com
>>>> >>> ><mailto:
>>>> >>> >>>>> alopresto.apache@gmail.com>
>>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>>>> EF69
>>>> >>> >>>>>
>>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <markap14@hotmail.com
>>>> >>> <mailto:m
>>>> >>> >>>>> arkap14@hotmail.com><ma...@hotmail.com>> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> Personally, I am afraid that if we don't set a Fix Version on
>>>> JIRA's,
>>>> >>> >>>
>>>> >>> >>> that
>>>> >>> >>>>>
>>>> >>> >>>>> some PR's will be lost
>>>> >>> >>>>> or stalled. I rarely go to github and start looking through the
>>>> PRs.
>>>> >>> >>>>> Instead, I go to JIRA and look
>>>> >>> >>>>> at what is assigned with a fixVersion of the next release. Then
>>>> I'll
>>>> >>> go
>>>> >>> >>>>> and review JIRA's that are
>>>> >>> >>>>> in a state of "Patch Available." Even then I often come across
>>>> many
>>>> >>> >>>>> PR's
>>>> >>> >>>>> that have already been
>>>> >>> >>>>> reviewed by one or more other committers and are awaiting
>>>> updates.
>>>> >>> >>>>>
>>>> >>> >>>>> So I propose that we address this slightly differently. I believe
>>>> >>> that
>>>> >>> >>>
>>>> >>> >>> we
>>>> >>> >>>>>
>>>> >>> >>>>> should assign a Fix Version to
>>>> >>> >>>>> a JIRA whenever a PR is submitted. Then, whenever a committer
>>>> >>> reviews a
>>>> >>> >>>>> PR, he/she should be
>>>> >>> >>>>> responsible for updating the JIRA. If the PR is merged then the
>>>> JIRA
>>>> >>> >>>>> should be resolved as Fixed.
>>>> >>> >>>>> But if the PR is not merged because some changes are needed, the
>>>> >>> >>>
>>>> >>> >>> reviewer
>>>> >>> >>>>>
>>>> >>> >>>>> should then go back to
>>>> >>> >>>>> the JIRA and click 'Cancel Patch'. We are typically very good
>>>> about
>>>> >>> >>>>> resolving as fixed once a PR is
>>>> >>> >>>>> merged, but we don't typically cancel the patch otherwise.
>>>> >>> >>>>>
>>>> >>> >>>>> If we followed this workflow, then a Release Manager (or anyone
>>>> else)
>>>> >>> >>>
>>>> >>> >>> can
>>>> >>> >>>>>
>>>> >>> >>>>> easily see which tickets
>>>> >>> >>>>> need to be reviewed before a release happens and which ones can
>>>> be
>>>> >>> >>>
>>>> >>> >>> pushed
>>>> >>> >>>>>
>>>> >>> >>>>> out because they
>>>> >>> >>>>> are not ready (even if a PR has been posted). It also makes it
>>>> much
>>>> >>> >>>
>>>> >>> >>> easier
>>>> >>> >>>>>
>>>> >>> >>>>> for reviewers to quickly
>>>> >>> >>>>> know which tickets are awaiting review.
>>>> >>> >>>>>
>>>> >>> >>>>> Thoughts?
>>>> >>> >>>>>
>>>> >>> >>>>> -Mark
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>> On Feb 23, 2017, at 3:37 AM, Andy LoPresto <
>>>> >>> alopresto.apache@gmail.com<
>>>> >>> >>>>> mailto:alopresto.apache@gmail.com><mailto:
>>>> alopresto.apache@gmail.com
>>>> >>> >>
>>>> >>> >>>>> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> As someone who has surely been guilty of optimistically setting
>>>> fix
>>>> >>> >>>>> versions and then not meeting them, I second Joe's point about it
>>>> >>> >>>
>>>> >>> >>> holding
>>>> >>> >>>>>
>>>> >>> >>>>> up releases. Better to get the PR out, reviewed, and merged
>>>> *before*
>>>> >>> >>>>> setting the fix version in my opinion.
>>>> >>> >>>>>
>>>> >>> >>>>> Andy LoPresto
>>>> >>> >>>>> alopresto@apache.org<ma...@apache.org><mailto:alo
>>>> >>> >>>>> presto@apache.org>
>>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com
>>>> >>> ><mailto:
>>>> >>> >>>>> alopresto.apache@gmail.com>
>>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>>>> EF69
>>>> >>> >>>>>
>>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.witt@gmail.com<mailto:
>>>> joe
>>>> >>> >>>>> .witt@gmail.com>> wrote:
>>>> >>> >>>>>
>>>> >>> >>>>> Peter,
>>>> >>> >>>>>
>>>> >>> >>>>> This is just my preference so discussion is certainly open.  But
>>>> the
>>>> >>> >>>>> way I see it we should not set the fix version on JIRAs unless
>>>> they
>>>> >>> >>>>> really should block a release without resolution or if due to
>>>> some
>>>> >>> >>>>> roadmap/planning/discussion it is a new feature/improvement that
>>>> is
>>>> >>> >>>>> tied to a release.  Otherwise, for the many things which pop up
>>>> >>> >>>>> throughout a given release cycle they should be avoided.  That
>>>> is to
>>>> >>> >>>>> say the majority of the time we'd avoid fix versions until the
>>>> act of
>>>> >>> >>>>> merging a contribution which also means it has been reviewed.
>>>> >>> >>>>>
>>>> >>> >>>>>  From the release management point of view:
>>>> >>> >>>>> This approach helps greatly as until now it is has been really
>>>> >>> >>>>> difficult and time consuming to pull together/close down a
>>>> release as
>>>> >>> >>>>> pretty much anyone can set these fix versions and make it appear
>>>> as
>>>> >>> >>>>> though the release is not ready when in reality it is perfectly
>>>> >>> >>>>> releasable as-is but might miss out on some contribs that someone
>>>> >>> >>>>> would like to see in the release but has as of yet not gotten
>>>> the PR
>>>> >>> >>>>> and/or review traction necessary.
>>>> >>> >>>>>
>>>> >>> >>>>>  From the contributor point of view:
>>>> >>> >>>>> If someone makes a contribution they obviously want that code to
>>>> end
>>>> >>> >>>>> up in a release.  But being an RTC community we need and want
>>>> peer
>>>> >>> >>>>> review before the code is submitted.  Some contributions are
>>>> frankly
>>>> >>> >>>>> hard to get peer review on or simply take time for someone to
>>>> >>> >>>>> volunteer to do.  PRs which are difficult to test, lack testing,
>>>> are
>>>> >>> >>>>> related to systems or environments which are not easily
>>>> replicated,
>>>> >>> >>>>> etc.. are inherently harder to get peer review for.  Also, the
>>>> >>> >>>>> community has grown quite rapidly and sometimes the hygiene of a
>>>> >>> given
>>>> >>> >>>>> PR isn't great.  So our 'patch available' and 'open PR' count
>>>> ticks
>>>> >>> >>>>> up.  We need reviews/feedback as much as we need contributions
>>>> so it
>>>> >>> >>>>> is important for folks that want those contributions in to build
>>>> >>> >>>>> meritocracy as well in reviewing others contributions.  This
>>>> helps
>>>> >>> >>>>> build a network of contributors/reviewers and improves the
>>>> timeliness
>>>> >>> >>>>> of reviews.  Long story short here is that because at times PRs
>>>> can
>>>> >>> >>>>> sit too long sometimes people put a fix version on the JIRA so it
>>>> >>> acts
>>>> >>> >>>>> as a sort of 'gating function' on the release.  This I am saying
>>>> is
>>>> >>> >>>>> the practice that should not occur (given the thoughts above).
>>>> We
>>>> >>> >>>>> should instead take the issue of how to more effectively
>>>> >>> >>>>> triage/review/provide feedback/and manage expectations for
>>>> >>> >>>>> contributions so contributors don't feel like their stuff will
>>>> just
>>>> >>> >>>>> sit forever.
>>>> >>> >>>>>
>>>> >>> >>>>> Does that make sense and seem fair?
>>>> >>> >>>>>
>>>> >>> >>>>> Thanks
>>>> >>> >>>>> Joe
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>> On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) <
>>>> >>> >>>
>>>> >>> >>> pwicks@micron.com
>>>> >>> >>>>>
>>>> >>> >>>>> <ma...@micron.com>> wrote:
>>>> >>> >>>>> Just for clarification, "We really need to avoid the practice of
>>>> >>> >>>>> setting
>>>> >>> >>>>> fix versions without traction", would mean don't set a version
>>>> number
>>>> >>> >>>
>>>> >>> >>> until
>>>> >>> >>>>>
>>>> >>> >>>>> after we've submitted a PR? Until after the PR has been closed?
>>>> >>> Other?
>>>> >>> >>>>>
>>>> >>> >>>>> Thanks,
>>>> >>> >>>>> Peter
>>>> >>> >>>>>
>>>> >>> >>>>> -----Original Message-----
>>>> >>> >>>>> From: Joe Witt [mailto:joe.witt@gmail.com]
>>>> >>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>>> >>> >>>>> To: dev@nifi.apache.org<ma...@nifi.apache.org>
>>>> >>> >>>>> Subject: Closing in on a NiFi 1.2.0 release?
>>>> >>> >>>>>
>>>> >>> >>>>> team,
>>>> >>> >>>>>
>>>> >>> >>>>> On the users lists we had an ask of when we are planning to cut a
>>>> >>> >>>>> 1.2.0 release.  And someone else asked me recently off-list.
>>>> >>> >>>>>
>>>> >>> >>>>> There are 45 open JIRAs tagged to it as of now.
>>>> >>> >>>>>
>>>> >>> >>>>> https://issues.apache.org/jira/issues/?jql=project%20%
>>>> >>> >>>>>
>>>> 3D%20NIFI%20AND%20fixVersion%20%3D%201.2.0%20AND%20resolution%20%3D%
>>>> >>> >>>>> 20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
>>>> >>> >>>>>
>>>> >>> >>>>> I'd be favorable to going through and seeing if we can start the
>>>> >>> >>>>> motions
>>>> >>> >>>>> for a 1.2.0 release and which are ones we can wait for and which
>>>> we
>>>> >>> >>>
>>>> >>> >>> should
>>>> >>> >>>>>
>>>> >>> >>>>> have in 1.2.0 for sure.
>>>> >>> >>>>>
>>>> >>> >>>>> Is there any reason folks can think of to hold off on a 1.2.0
>>>> >>> release?
>>>> >>> >>>>>
>>>> >>> >>>>> A non trivial number of the JIRAs are for things which have or
>>>> do not
>>>> >>> >>>
>>>> >>> >>> have
>>>> >>> >>>>>
>>>> >>> >>>>> PRs but have no review traction.  We really need to avoid the
>>>> >>> practice
>>>> >>> >>>
>>>> >>> >>> of
>>>> >>> >>>>>
>>>> >>> >>>>> setting fix versions without traction on this as otherwise it
>>>> holds
>>>> >>> up
>>>> >>> >>>
>>>> >>> >>> the
>>>> >>> >>>>>
>>>> >>> >>>>> releases.
>>>> >>> >>>>>
>>>> >>> >>>>> Thanks
>>>> >>> >>>>> Joe
>>>> >>> >>>>>
>>>> >>> >>>>>
>>>> >>> >>>>
>>>> >>> >>>> --
>>>> >>> >>>> I know what it is to be in need, and I know what it is to have
>>>> plenty.
>>>> >>> >>>> I
>>>> >>> >>>> have learned the secret of being content in any and every
>>>> situation,
>>>> >>> >>>> whether well fed or hungry, whether living in plenty or in want.
>>>> I
>>>> >>> can
>>>> >>> >>>
>>>> >>> >>> do
>>>> >>> >>>>
>>>> >>> >>>> all this through him who gives me strength.    *-Philippians
>>>> 4:12-13*
>>>> >>> >
>>>> >>> >
>>>> >>>
>>>>
>>> --
>>> Sent from Gmail Mobile

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende <bb...@gmail.com>]

Quick update...

I was looking through PRs and noticed that NIFI-3594 (Encrypted Prov
Repo) had already received a +1 and just needed an update to resolve
conflicts with master.  I spoke to Andy offline and he is planning to
resolve the conflicts shortly and we can include this in 1.2.0.

Also, NIFI-3726 (CompareFuzzyHash processor) appears to be very close
as well and has already had some review and updates made. Andy plans
to do a final review and hopefully merge this as well.

Thanks,

Bryan




On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
> All,
>
> Looks like we are closer than we have ever been!
>
> Down to three outstanding JIRAs...
>
> - NIFI-1833 (Azure Processors) - Active review and discussion
> occurring, appears to be close
> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
> this may be moved from the release to a separate effort
> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
> like it could be merged relatively soon
>
> Once these are finalized we should be able to start the RC process.
>
> I've started putting together the release notes on the Wiki (still a
> work in progress):
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.2.0
>
> If anyone knows of anything that should be highlighted, feel free to
> mention it here and I can update the notes.
>
> Thanks!
>
> -Bryan
>
>
> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>> Looks like we are down to just a few tickets, and all of them seem to
>> have traction in terms of review and discussion.
>>
>> I'll keep an eye on the tickets and start trying to pull together
>> anything I can to get ready for the RC process. Seems like we are
>> close!
>>
>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <ru...@windofkeltia.com> wrote:
>>> Many thanks to all the industrious folk working on this tool that's become
>>> indispensable to so many. The community has my enduring gratitude and
>>> admiration!
>>>
>>> Russ
>>>
>>>
>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>>
>>>> Robert,
>>>>
>>>> We're about 10 or so JIRAs away at this point and all of them have PRs
>>>> and progress on them.  We need to close those down and do some
>>>> stabilization/testing then a release candidate can happen.  So perhaps
>>>> next week we'll be at that point and have a release.  This is the
>>>> right place to be watching to see it closing in.
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> is there any date set for 1.2.0 release yet?
>>>>> We are running into an  NIFI-3389
>>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would like
>>>>> to
>>>>> know when we can expect 1.2.0 release to be available.
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>>> Nabble.com.
>>>
>>>

Re: Closing in on a NiFi 1.2.0 release?

[Joe Gresock <jg...@gmail.com>]

Would it be appropriate to add mention of the 2 new site-to-site reporting
tasks (status and bulletin) in the release notes?

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, May 4, 2017 at 1:20 PM, Bryan Bende <bb...@gmail.com> wrote:

> The issues from yesterday have been resolved so I'll start kicking off
> another attempt at the RC process.
>
>
> On Wed, May 3, 2017 at 6:10 PM, Bryan Bende <bb...@gmail.com> wrote:
>
> > Quick update... I ran into two issues that will need to be addressed to
> > create the RC.
> >
> > I've created JIRAs for them and tagged them as 1.2:
> >
> > https://issues.apache.org/jira/browse/NIFI-3795
> > https://issues.apache.org/jira/browse/NIFI-3793
> >
> >
> > On Wed, May 3, 2017 at 2:41 PM, Bryan Bende <bb...@gmail.com> wrote:
> >
> >> Looks like all of the JIRAs have been resolved and we are in a good
> place.
> >>
> >> I'll begin kicking off the RC process.
> >>
> >> On Tue, May 2, 2017 at 5:48 PM, Andre <an...@fucs.org> wrote:
> >>
> >>> All,
> >>>
> >>> For some reason my canvas did not refresh after a process bounce (which
> >>> generally occurs) but reloading page allows for modifications.
> >>>
> >>> Cheers
> >>>
> >>> On Wed, May 3, 2017 at 7:43 AM, Andre <an...@fucs.org> wrote:
> >>>
> >>>> folks,
> >>>>
> >>>> I was just working to debug the final thorns found reviewing NIFI-3726
> >>>> and noticed an odd behavior and wanted to confirm.
> >>>>
> >>>> If I recall correctly in the past users could simply replace a
> >>>> processor NAR file and even if that NAR existed the flow would
> continue to
> >>>> work.
> >>>>
> >>>> I just replaced
> >>>>
> >>>> cp ~/nifi/nifi-nar-bundles/nifi-cybersecurity-bundle/nifi-cyber
> >>>> security-nar/target/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
> >>>> ~/devel/nifi-1.2.0-SNAPSHOT/lib/nifi-cybersecurity-nar-1.2.0
> >>>> -SNAPSHOT.nar
> >>>>
> >>>> (note the different ~/nifi ~/devel used to ensure I don't explode the
> >>>> rest of the already compiled components).
> >>>>
> >>>> When I try to make changes to the flow I am displayed with the
> >>>> following error:
> >>>>
> >>>> [image: Inline image 1]
> >>>>
> >>>> This happens even when I try to drag and drop connected processors
> >>>> around the canvas.
> >>>>
> >>>>
> >>>> Oddly enough I can still add and delete components to the canvas but
> >>>> whatever touches the tainted processor cannot be modified at all.
> >>>>
> >>>> Examples of messages:
> >>>>
> >>>> *Attempt to move*
> >>>>
> >>>> Component Position
> >>>> [5, cb0a31ac-015b-1000-7473-873a47eb702e,
> >>>> cb0a52ab-015b-1000-e43a-f6293a9ae99d] is not the most up-to-date
> >>>> revision. This component appears to have been modified
> >>>>
> >>>>
> >>>> *Attempt to delete a downstream processor*
> >>>> Error
> >>>> [1, cb0a31ac-015b-1000-7473-873a47eb702e,
> >>>> cb0b2ae4-015b-1000-35a8-9eaf6a45fc6a] is not the most up-to-date
> >>>> revision. This component appears to have been modified
> >>>>
> >>>>
> >>>> I don't have a 1.1.0 instance around me at the moment but I vaguely
> >>>> remember being able to do that in the past.
> >>>>
> >>>> Can someone confirm this is new and expected behavior?
> >>>>
> >>>> Cheers
> >>>>
> >>>>
> >>>> On Wed, May 3, 2017 at 5:54 AM, Andy LoPresto <al...@apache.org>
> >>>> wrote:
> >>>>
> >>>>> I’ll review & merge as soon as they are available.
> >>>>>
> >>>>> Andy LoPresto
> >>>>> alopresto@apache.org
> >>>>> *alopresto.apache@gmail.com <al...@gmail.com>*
> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>>>>
> >>>>> On May 2, 2017, at 3:51 PM, Bryan Bende <bb...@gmail.com> wrote:
> >>>>>
> >>>>> Thanks Drew. These seem like good candidates for the release.
> >>>>>
> >>>>> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <
> andrewlim.apache@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> There are three doc updates/additions that would be great to include
> >>>>> in the RC:
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/NIFI-3701
> >>>>> https://issues.apache.org/jira/browse/NIFI-3773
> >>>>> https://issues.apache.org/jira/browse/NIFI-3774
> >>>>>
> >>>>> Sarah Olson and I have been working on these.  We should have PRs
> >>>>> submitted for them very soon.
> >>>>>
> >>>>> -Drew
> >>>>>
> >>>>>
> >>>>> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com>
> wrote:
> >>>>>
> >>>>> Haven't had much luck in getting our Docker efforts incorporated into
> >>>>> Docker Hub.  As a result I have created an issue to track that
> >>>>> integration
> >>>>> [1] and resolved the original issue.
> >>>>>
> >>>>> We can evaluate our options and figure out the best path forward.  At
> >>>>> this
> >>>>> time procedures are not yet well established within ASF to support
> >>>>> configuring these builds.
> >>>>>
> >>>>> [1] https://issues.apache.org/jira/browse/NIFI-3772
> >>>>>
> >>>>> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <
> >>>>> andrewlim.apache@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>> I will be making updates to the Release Notes and Migration Guidance
> >>>>> doc
> >>>>> regarding the TLS 1.2 version support.  Tracked by:
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/NIFI-3720
> >>>>>
> >>>>>
> >>>>> -Drew
> >>>>>
> >>>>>
> >>>>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
> >>>>>
> >>>>> Those are great updates.  I'd recommend we avoid highlighting the
> >>>>> versions of UI components though.
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>>
> >>>>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>> Hey Bryan,
> >>>>>
> >>>>> Please include the following in the release notes:
> >>>>>
> >>>>>
> >>>>> - Core UI
> >>>>>    - Circular references have been removed and the code modularized.
> >>>>>    - Upgraded Node version to 6.9.3.
> >>>>>    - Upgraded npm version to 3.10.10.
> >>>>>    - Upgraded jQuery version to 3.1.1.
> >>>>>    - Upgraded D3 version to 3.5.17.
> >>>>>    - Reduced download size by removing bundled dependencies.
> >>>>> - User Experience Improvements
> >>>>> - Ever wish that it was easier to align components on the canvas? Me
> >>>>>    too...and now you can!
> >>>>>    - We now provide deep links to any component(s) on the canvas.
> This
> >>>>>    will help make collaborating and sharing more natural.
> >>>>>    - Users will enjoy a better understanding of the scope of
> >>>>>
> >>>>> Controller
> >>>>>
> >>>>>    Services through an improved experience.
> >>>>>    - All actions available on the operate palette are now also
> >>>>>
> >>>>> available
> >>>>>
> >>>>>    under the context menu too!
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com>
> wrote:
> >>>>>
> >>>>> All,
> >>>>>
> >>>>> Looks like we are closer than we have ever been!
> >>>>>
> >>>>> Down to three outstanding JIRAs...
> >>>>>
> >>>>> - NIFI-1833 (Azure Processors) - Active review and discussion
> >>>>> occurring, appears to be close
> >>>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
> >>>>> this may be moved from the release to a separate effort
> >>>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
> >>>>> like it could be merged relatively soon
> >>>>>
> >>>>> Once these are finalized we should be able to start the RC process.
> >>>>>
> >>>>> I've started putting together the release notes on the Wiki (still a
> >>>>> work in progress):
> >>>>> https://cwiki.apache.org/confluence/display/NIFI/
> >>>>> Release+Notes#ReleaseNotes-Version1.2.0
> >>>>>
> >>>>> If anyone knows of anything that should be highlighted, feel free to
> >>>>> mention it here and I can update the notes.
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> -Bryan
> >>>>>
> >>>>>
> >>>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com>
> wrote:
> >>>>>
> >>>>> Looks like we are down to just a few tickets, and all of them seem to
> >>>>> have traction in terms of review and discussion.
> >>>>>
> >>>>> I'll keep an eye on the tickets and start trying to pull together
> >>>>> anything I can to get ready for the RC process. Seems like we are
> >>>>> close!
> >>>>>
> >>>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
> >>>>>
> >>>>> russ@windofkeltia.com>
> >>>>>
> >>>>> wrote:
> >>>>>
> >>>>> Many thanks to all the industrious folk working on this tool that's
> >>>>>
> >>>>> become
> >>>>>
> >>>>> indispensable to so many. The community has my enduring gratitude and
> >>>>> admiration!
> >>>>>
> >>>>> Russ
> >>>>>
> >>>>>
> >>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
> >>>>>
> >>>>>
> >>>>> Robert,
> >>>>>
> >>>>> We're about 10 or so JIRAs away at this point and all of them have
> >>>>>
> >>>>> PRs
> >>>>>
> >>>>> and progress on them.  We need to close those down and do some
> >>>>> stabilization/testing then a release candidate can happen.  So
> >>>>>
> >>>>> perhaps
> >>>>>
> >>>>> next week we'll be at that point and have a release.  This is the
> >>>>> right place to be watching to see it closing in.
> >>>>>
> >>>>> Thanks
> >>>>> Joe
> >>>>>
> >>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
> >>>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> is there any date set for 1.2.0 release yet?
> >>>>> We are running into an  NIFI-3389
> >>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
> >>>>>
> >>>>> would
> >>>>>
> >>>>> like
> >>>>>
> >>>>> to
> >>>>> know when we can expect 1.2.0 release to be available.
> >>>>>
> >>>>> Thanks,
> >>>>> Robert
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> View this message in context:
> >>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
> >>>>>
> >>>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
> >>>>>
> >>>>> Sent from the Apache NiFi Developer List mailing list archive at
> >>>>> Nabble.com.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> *Scott Aslan = new WebDeveloper(*
> >>>>> *{    "location": {        "city": "Saint Cloud",        "state":
> "FL",
> >>>>>  "zip": "34771"    },    "contact": {        "email":
> >>>>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
> >>>>> "http://www.linkedin.com/in/scottyaslan
> >>>>> <http://www.linkedin.com/in/scottaslan>"    }});*
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>



-- 
I know what it is to be in need, and I know what it is to have plenty.  I
have learned the secret of being content in any and every situation,
whether well fed or hungry, whether living in plenty or in want.  I can do
all this through him who gives me strength.    *-Philippians 4:12-13*

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende <bb...@gmail.com>]

The issues from yesterday have been resolved so I'll start kicking off
another attempt at the RC process.


On Wed, May 3, 2017 at 6:10 PM, Bryan Bende <bb...@gmail.com> wrote:

> Quick update... I ran into two issues that will need to be addressed to
> create the RC.
>
> I've created JIRAs for them and tagged them as 1.2:
>
> https://issues.apache.org/jira/browse/NIFI-3795
> https://issues.apache.org/jira/browse/NIFI-3793
>
>
> On Wed, May 3, 2017 at 2:41 PM, Bryan Bende <bb...@gmail.com> wrote:
>
>> Looks like all of the JIRAs have been resolved and we are in a good place.
>>
>> I'll begin kicking off the RC process.
>>
>> On Tue, May 2, 2017 at 5:48 PM, Andre <an...@fucs.org> wrote:
>>
>>> All,
>>>
>>> For some reason my canvas did not refresh after a process bounce (which
>>> generally occurs) but reloading page allows for modifications.
>>>
>>> Cheers
>>>
>>> On Wed, May 3, 2017 at 7:43 AM, Andre <an...@fucs.org> wrote:
>>>
>>>> folks,
>>>>
>>>> I was just working to debug the final thorns found reviewing NIFI-3726
>>>> and noticed an odd behavior and wanted to confirm.
>>>>
>>>> If I recall correctly in the past users could simply replace a
>>>> processor NAR file and even if that NAR existed the flow would continue to
>>>> work.
>>>>
>>>> I just replaced
>>>>
>>>> cp ~/nifi/nifi-nar-bundles/nifi-cybersecurity-bundle/nifi-cyber
>>>> security-nar/target/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
>>>> ~/devel/nifi-1.2.0-SNAPSHOT/lib/nifi-cybersecurity-nar-1.2.0
>>>> -SNAPSHOT.nar
>>>>
>>>> (note the different ~/nifi ~/devel used to ensure I don't explode the
>>>> rest of the already compiled components).
>>>>
>>>> When I try to make changes to the flow I am displayed with the
>>>> following error:
>>>>
>>>> [image: Inline image 1]
>>>>
>>>> This happens even when I try to drag and drop connected processors
>>>> around the canvas.
>>>>
>>>>
>>>> Oddly enough I can still add and delete components to the canvas but
>>>> whatever touches the tainted processor cannot be modified at all.
>>>>
>>>> Examples of messages:
>>>>
>>>> *Attempt to move*
>>>>
>>>> Component Position
>>>> [5, cb0a31ac-015b-1000-7473-873a47eb702e,
>>>> cb0a52ab-015b-1000-e43a-f6293a9ae99d] is not the most up-to-date
>>>> revision. This component appears to have been modified
>>>>
>>>>
>>>> *Attempt to delete a downstream processor*
>>>> Error
>>>> [1, cb0a31ac-015b-1000-7473-873a47eb702e,
>>>> cb0b2ae4-015b-1000-35a8-9eaf6a45fc6a] is not the most up-to-date
>>>> revision. This component appears to have been modified
>>>>
>>>>
>>>> I don't have a 1.1.0 instance around me at the moment but I vaguely
>>>> remember being able to do that in the past.
>>>>
>>>> Can someone confirm this is new and expected behavior?
>>>>
>>>> Cheers
>>>>
>>>>
>>>> On Wed, May 3, 2017 at 5:54 AM, Andy LoPresto <al...@apache.org>
>>>> wrote:
>>>>
>>>>> I’ll review & merge as soon as they are available.
>>>>>
>>>>> Andy LoPresto
>>>>> alopresto@apache.org
>>>>> *alopresto.apache@gmail.com <al...@gmail.com>*
>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>>
>>>>> On May 2, 2017, at 3:51 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>
>>>>> Thanks Drew. These seem like good candidates for the release.
>>>>>
>>>>> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <an...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> There are three doc updates/additions that would be great to include
>>>>> in the RC:
>>>>>
>>>>> https://issues.apache.org/jira/browse/NIFI-3701
>>>>> https://issues.apache.org/jira/browse/NIFI-3773
>>>>> https://issues.apache.org/jira/browse/NIFI-3774
>>>>>
>>>>> Sarah Olson and I have been working on these.  We should have PRs
>>>>> submitted for them very soon.
>>>>>
>>>>> -Drew
>>>>>
>>>>>
>>>>> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
>>>>>
>>>>> Haven't had much luck in getting our Docker efforts incorporated into
>>>>> Docker Hub.  As a result I have created an issue to track that
>>>>> integration
>>>>> [1] and resolved the original issue.
>>>>>
>>>>> We can evaluate our options and figure out the best path forward.  At
>>>>> this
>>>>> time procedures are not yet well established within ASF to support
>>>>> configuring these builds.
>>>>>
>>>>> [1] https://issues.apache.org/jira/browse/NIFI-3772
>>>>>
>>>>> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <
>>>>> andrewlim.apache@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I will be making updates to the Release Notes and Migration Guidance
>>>>> doc
>>>>> regarding the TLS 1.2 version support.  Tracked by:
>>>>>
>>>>> https://issues.apache.org/jira/browse/NIFI-3720
>>>>>
>>>>>
>>>>> -Drew
>>>>>
>>>>>
>>>>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>>>>>
>>>>> Those are great updates.  I'd recommend we avoid highlighting the
>>>>> versions of UI components though.
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>> Hey Bryan,
>>>>>
>>>>> Please include the following in the release notes:
>>>>>
>>>>>
>>>>> - Core UI
>>>>>    - Circular references have been removed and the code modularized.
>>>>>    - Upgraded Node version to 6.9.3.
>>>>>    - Upgraded npm version to 3.10.10.
>>>>>    - Upgraded jQuery version to 3.1.1.
>>>>>    - Upgraded D3 version to 3.5.17.
>>>>>    - Reduced download size by removing bundled dependencies.
>>>>> - User Experience Improvements
>>>>> - Ever wish that it was easier to align components on the canvas? Me
>>>>>    too...and now you can!
>>>>>    - We now provide deep links to any component(s) on the canvas. This
>>>>>    will help make collaborating and sharing more natural.
>>>>>    - Users will enjoy a better understanding of the scope of
>>>>>
>>>>> Controller
>>>>>
>>>>>    Services through an improved experience.
>>>>>    - All actions available on the operate palette are now also
>>>>>
>>>>> available
>>>>>
>>>>>    under the context menu too!
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> Looks like we are closer than we have ever been!
>>>>>
>>>>> Down to three outstanding JIRAs...
>>>>>
>>>>> - NIFI-1833 (Azure Processors) - Active review and discussion
>>>>> occurring, appears to be close
>>>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>>>>> this may be moved from the release to a separate effort
>>>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>>>>> like it could be merged relatively soon
>>>>>
>>>>> Once these are finalized we should be able to start the RC process.
>>>>>
>>>>> I've started putting together the release notes on the Wiki (still a
>>>>> work in progress):
>>>>> https://cwiki.apache.org/confluence/display/NIFI/
>>>>> Release+Notes#ReleaseNotes-Version1.2.0
>>>>>
>>>>> If anyone knows of anything that should be highlighted, feel free to
>>>>> mention it here and I can update the notes.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> -Bryan
>>>>>
>>>>>
>>>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>
>>>>> Looks like we are down to just a few tickets, and all of them seem to
>>>>> have traction in terms of review and discussion.
>>>>>
>>>>> I'll keep an eye on the tickets and start trying to pull together
>>>>> anything I can to get ready for the RC process. Seems like we are
>>>>> close!
>>>>>
>>>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>>>>>
>>>>> russ@windofkeltia.com>
>>>>>
>>>>> wrote:
>>>>>
>>>>> Many thanks to all the industrious folk working on this tool that's
>>>>>
>>>>> become
>>>>>
>>>>> indispensable to so many. The community has my enduring gratitude and
>>>>> admiration!
>>>>>
>>>>> Russ
>>>>>
>>>>>
>>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>>>
>>>>>
>>>>> Robert,
>>>>>
>>>>> We're about 10 or so JIRAs away at this point and all of them have
>>>>>
>>>>> PRs
>>>>>
>>>>> and progress on them.  We need to close those down and do some
>>>>> stabilization/testing then a release candidate can happen.  So
>>>>>
>>>>> perhaps
>>>>>
>>>>> next week we'll be at that point and have a release.  This is the
>>>>> right place to be watching to see it closing in.
>>>>>
>>>>> Thanks
>>>>> Joe
>>>>>
>>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> is there any date set for 1.2.0 release yet?
>>>>> We are running into an  NIFI-3389
>>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>>>>>
>>>>> would
>>>>>
>>>>> like
>>>>>
>>>>> to
>>>>> know when we can expect 1.2.0 release to be available.
>>>>>
>>>>> Thanks,
>>>>> Robert
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>>>>
>>>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>>>
>>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>>> Nabble.com.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Scott Aslan = new WebDeveloper(*
>>>>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>>>>  "zip": "34771"    },    "contact": {        "email":
>>>>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>>>>> "http://www.linkedin.com/in/scottyaslan
>>>>> <http://www.linkedin.com/in/scottaslan>"    }});*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende <bb...@gmail.com>]

Quick update... I ran into two issues that will need to be addressed to
create the RC.

I've created JIRAs for them and tagged them as 1.2:

https://issues.apache.org/jira/browse/NIFI-3795
https://issues.apache.org/jira/browse/NIFI-3793


On Wed, May 3, 2017 at 2:41 PM, Bryan Bende <bb...@gmail.com> wrote:

> Looks like all of the JIRAs have been resolved and we are in a good place.
>
> I'll begin kicking off the RC process.
>
> On Tue, May 2, 2017 at 5:48 PM, Andre <an...@fucs.org> wrote:
>
>> All,
>>
>> For some reason my canvas did not refresh after a process bounce (which
>> generally occurs) but reloading page allows for modifications.
>>
>> Cheers
>>
>> On Wed, May 3, 2017 at 7:43 AM, Andre <an...@fucs.org> wrote:
>>
>>> folks,
>>>
>>> I was just working to debug the final thorns found reviewing NIFI-3726
>>> and noticed an odd behavior and wanted to confirm.
>>>
>>> If I recall correctly in the past users could simply replace a processor
>>> NAR file and even if that NAR existed the flow would continue to work.
>>>
>>> I just replaced
>>>
>>> cp ~/nifi/nifi-nar-bundles/nifi-cybersecurity-bundle/nifi-cyber
>>> security-nar/target/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
>>> ~/devel/nifi-1.2.0-SNAPSHOT/lib/nifi-cybersecurity-nar-1.2.0
>>> -SNAPSHOT.nar
>>>
>>> (note the different ~/nifi ~/devel used to ensure I don't explode the
>>> rest of the already compiled components).
>>>
>>> When I try to make changes to the flow I am displayed with the following
>>> error:
>>>
>>> [image: Inline image 1]
>>>
>>> This happens even when I try to drag and drop connected processors
>>> around the canvas.
>>>
>>>
>>> Oddly enough I can still add and delete components to the canvas but
>>> whatever touches the tainted processor cannot be modified at all.
>>>
>>> Examples of messages:
>>>
>>> *Attempt to move*
>>>
>>> Component Position
>>> [5, cb0a31ac-015b-1000-7473-873a47eb702e, cb0a52ab-015b-1000-e43a-f6293a9ae99d]
>>> is not the most up-to-date revision. This component appears to have been
>>> modified
>>>
>>>
>>> *Attempt to delete a downstream processor*
>>> Error
>>> [1, cb0a31ac-015b-1000-7473-873a47eb702e, cb0b2ae4-015b-1000-35a8-9eaf6a45fc6a]
>>> is not the most up-to-date revision. This component appears to have been
>>> modified
>>>
>>>
>>> I don't have a 1.1.0 instance around me at the moment but I vaguely
>>> remember being able to do that in the past.
>>>
>>> Can someone confirm this is new and expected behavior?
>>>
>>> Cheers
>>>
>>>
>>> On Wed, May 3, 2017 at 5:54 AM, Andy LoPresto <al...@apache.org>
>>> wrote:
>>>
>>>> I’ll review & merge as soon as they are available.
>>>>
>>>> Andy LoPresto
>>>> alopresto@apache.org
>>>> *alopresto.apache@gmail.com <al...@gmail.com>*
>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>
>>>> On May 2, 2017, at 3:51 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>
>>>> Thanks Drew. These seem like good candidates for the release.
>>>>
>>>> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <an...@gmail.com>
>>>> wrote:
>>>>
>>>> There are three doc updates/additions that would be great to include in
>>>> the RC:
>>>>
>>>> https://issues.apache.org/jira/browse/NIFI-3701
>>>> https://issues.apache.org/jira/browse/NIFI-3773
>>>> https://issues.apache.org/jira/browse/NIFI-3774
>>>>
>>>> Sarah Olson and I have been working on these.  We should have PRs
>>>> submitted for them very soon.
>>>>
>>>> -Drew
>>>>
>>>>
>>>> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
>>>>
>>>> Haven't had much luck in getting our Docker efforts incorporated into
>>>> Docker Hub.  As a result I have created an issue to track that
>>>> integration
>>>> [1] and resolved the original issue.
>>>>
>>>> We can evaluate our options and figure out the best path forward.  At
>>>> this
>>>> time procedures are not yet well established within ASF to support
>>>> configuring these builds.
>>>>
>>>> [1] https://issues.apache.org/jira/browse/NIFI-3772
>>>>
>>>> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <andrewlim.apache@gmail.com
>>>> >
>>>> wrote:
>>>>
>>>> I will be making updates to the Release Notes and Migration Guidance doc
>>>> regarding the TLS 1.2 version support.  Tracked by:
>>>>
>>>> https://issues.apache.org/jira/browse/NIFI-3720
>>>>
>>>>
>>>> -Drew
>>>>
>>>>
>>>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>>>>
>>>> Those are great updates.  I'd recommend we avoid highlighting the
>>>> versions of UI components though.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>>>>
>>>> wrote:
>>>>
>>>> Hey Bryan,
>>>>
>>>> Please include the following in the release notes:
>>>>
>>>>
>>>> - Core UI
>>>>    - Circular references have been removed and the code modularized.
>>>>    - Upgraded Node version to 6.9.3.
>>>>    - Upgraded npm version to 3.10.10.
>>>>    - Upgraded jQuery version to 3.1.1.
>>>>    - Upgraded D3 version to 3.5.17.
>>>>    - Reduced download size by removing bundled dependencies.
>>>> - User Experience Improvements
>>>> - Ever wish that it was easier to align components on the canvas? Me
>>>>    too...and now you can!
>>>>    - We now provide deep links to any component(s) on the canvas. This
>>>>    will help make collaborating and sharing more natural.
>>>>    - Users will enjoy a better understanding of the scope of
>>>>
>>>> Controller
>>>>
>>>>    Services through an improved experience.
>>>>    - All actions available on the operate palette are now also
>>>>
>>>> available
>>>>
>>>>    under the context menu too!
>>>>
>>>> Thanks!
>>>>
>>>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>>>>
>>>> All,
>>>>
>>>> Looks like we are closer than we have ever been!
>>>>
>>>> Down to three outstanding JIRAs...
>>>>
>>>> - NIFI-1833 (Azure Processors) - Active review and discussion
>>>> occurring, appears to be close
>>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>>>> this may be moved from the release to a separate effort
>>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>>>> like it could be merged relatively soon
>>>>
>>>> Once these are finalized we should be able to start the RC process.
>>>>
>>>> I've started putting together the release notes on the Wiki (still a
>>>> work in progress):
>>>> https://cwiki.apache.org/confluence/display/NIFI/
>>>> Release+Notes#ReleaseNotes-Version1.2.0
>>>>
>>>> If anyone knows of anything that should be highlighted, feel free to
>>>> mention it here and I can update the notes.
>>>>
>>>> Thanks!
>>>>
>>>> -Bryan
>>>>
>>>>
>>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>
>>>> Looks like we are down to just a few tickets, and all of them seem to
>>>> have traction in terms of review and discussion.
>>>>
>>>> I'll keep an eye on the tickets and start trying to pull together
>>>> anything I can to get ready for the RC process. Seems like we are
>>>> close!
>>>>
>>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>>>>
>>>> russ@windofkeltia.com>
>>>>
>>>> wrote:
>>>>
>>>> Many thanks to all the industrious folk working on this tool that's
>>>>
>>>> become
>>>>
>>>> indispensable to so many. The community has my enduring gratitude and
>>>> admiration!
>>>>
>>>> Russ
>>>>
>>>>
>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>>
>>>>
>>>> Robert,
>>>>
>>>> We're about 10 or so JIRAs away at this point and all of them have
>>>>
>>>> PRs
>>>>
>>>> and progress on them.  We need to close those down and do some
>>>> stabilization/testing then a release candidate can happen.  So
>>>>
>>>> perhaps
>>>>
>>>> next week we'll be at that point and have a release.  This is the
>>>> right place to be watching to see it closing in.
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> is there any date set for 1.2.0 release yet?
>>>> We are running into an  NIFI-3389
>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>>>>
>>>> would
>>>>
>>>> like
>>>>
>>>> to
>>>> know when we can expect 1.2.0 release to be available.
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>>>
>>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>>
>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>> Nabble.com.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Scott Aslan = new WebDeveloper(*
>>>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>>>  "zip": "34771"    },    "contact": {        "email":
>>>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>>>> "http://www.linkedin.com/in/scottyaslan
>>>> <http://www.linkedin.com/in/scottaslan>"    }});*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende <bb...@gmail.com>]

Looks like all of the JIRAs have been resolved and we are in a good place.

I'll begin kicking off the RC process.

On Tue, May 2, 2017 at 5:48 PM, Andre <an...@fucs.org> wrote:

> All,
>
> For some reason my canvas did not refresh after a process bounce (which
> generally occurs) but reloading page allows for modifications.
>
> Cheers
>
> On Wed, May 3, 2017 at 7:43 AM, Andre <an...@fucs.org> wrote:
>
>> folks,
>>
>> I was just working to debug the final thorns found reviewing NIFI-3726
>> and noticed an odd behavior and wanted to confirm.
>>
>> If I recall correctly in the past users could simply replace a processor
>> NAR file and even if that NAR existed the flow would continue to work.
>>
>> I just replaced
>>
>> cp ~/nifi/nifi-nar-bundles/nifi-cybersecurity-bundle/nifi-cyber
>> security-nar/target/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
>> ~/devel/nifi-1.2.0-SNAPSHOT/lib/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
>>
>> (note the different ~/nifi ~/devel used to ensure I don't explode the
>> rest of the already compiled components).
>>
>> When I try to make changes to the flow I am displayed with the following
>> error:
>>
>> [image: Inline image 1]
>>
>> This happens even when I try to drag and drop connected processors around
>> the canvas.
>>
>>
>> Oddly enough I can still add and delete components to the canvas but
>> whatever touches the tainted processor cannot be modified at all.
>>
>> Examples of messages:
>>
>> *Attempt to move*
>>
>> Component Position
>> [5, cb0a31ac-015b-1000-7473-873a47eb702e, cb0a52ab-015b-1000-e43a-f6293a9ae99d]
>> is not the most up-to-date revision. This component appears to have been
>> modified
>>
>>
>> *Attempt to delete a downstream processor*
>> Error
>> [1, cb0a31ac-015b-1000-7473-873a47eb702e, cb0b2ae4-015b-1000-35a8-9eaf6a45fc6a]
>> is not the most up-to-date revision. This component appears to have been
>> modified
>>
>>
>> I don't have a 1.1.0 instance around me at the moment but I vaguely
>> remember being able to do that in the past.
>>
>> Can someone confirm this is new and expected behavior?
>>
>> Cheers
>>
>>
>> On Wed, May 3, 2017 at 5:54 AM, Andy LoPresto <al...@apache.org>
>> wrote:
>>
>>> I’ll review & merge as soon as they are available.
>>>
>>> Andy LoPresto
>>> alopresto@apache.org
>>> *alopresto.apache@gmail.com <al...@gmail.com>*
>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>
>>> On May 2, 2017, at 3:51 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>
>>> Thanks Drew. These seem like good candidates for the release.
>>>
>>> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <an...@gmail.com>
>>> wrote:
>>>
>>> There are three doc updates/additions that would be great to include in
>>> the RC:
>>>
>>> https://issues.apache.org/jira/browse/NIFI-3701
>>> https://issues.apache.org/jira/browse/NIFI-3773
>>> https://issues.apache.org/jira/browse/NIFI-3774
>>>
>>> Sarah Olson and I have been working on these.  We should have PRs
>>> submitted for them very soon.
>>>
>>> -Drew
>>>
>>>
>>> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
>>>
>>> Haven't had much luck in getting our Docker efforts incorporated into
>>> Docker Hub.  As a result I have created an issue to track that
>>> integration
>>> [1] and resolved the original issue.
>>>
>>> We can evaluate our options and figure out the best path forward.  At
>>> this
>>> time procedures are not yet well established within ASF to support
>>> configuring these builds.
>>>
>>> [1] https://issues.apache.org/jira/browse/NIFI-3772
>>>
>>> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <an...@gmail.com>
>>> wrote:
>>>
>>> I will be making updates to the Release Notes and Migration Guidance doc
>>> regarding the TLS 1.2 version support.  Tracked by:
>>>
>>> https://issues.apache.org/jira/browse/NIFI-3720
>>>
>>>
>>> -Drew
>>>
>>>
>>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>>>
>>> Those are great updates.  I'd recommend we avoid highlighting the
>>> versions of UI components though.
>>>
>>> Thanks
>>>
>>>
>>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>>>
>>> wrote:
>>>
>>> Hey Bryan,
>>>
>>> Please include the following in the release notes:
>>>
>>>
>>> - Core UI
>>>    - Circular references have been removed and the code modularized.
>>>    - Upgraded Node version to 6.9.3.
>>>    - Upgraded npm version to 3.10.10.
>>>    - Upgraded jQuery version to 3.1.1.
>>>    - Upgraded D3 version to 3.5.17.
>>>    - Reduced download size by removing bundled dependencies.
>>> - User Experience Improvements
>>> - Ever wish that it was easier to align components on the canvas? Me
>>>    too...and now you can!
>>>    - We now provide deep links to any component(s) on the canvas. This
>>>    will help make collaborating and sharing more natural.
>>>    - Users will enjoy a better understanding of the scope of
>>>
>>> Controller
>>>
>>>    Services through an improved experience.
>>>    - All actions available on the operate palette are now also
>>>
>>> available
>>>
>>>    under the context menu too!
>>>
>>> Thanks!
>>>
>>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>>>
>>> All,
>>>
>>> Looks like we are closer than we have ever been!
>>>
>>> Down to three outstanding JIRAs...
>>>
>>> - NIFI-1833 (Azure Processors) - Active review and discussion
>>> occurring, appears to be close
>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>>> this may be moved from the release to a separate effort
>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>>> like it could be merged relatively soon
>>>
>>> Once these are finalized we should be able to start the RC process.
>>>
>>> I've started putting together the release notes on the Wiki (still a
>>> work in progress):
>>> https://cwiki.apache.org/confluence/display/NIFI/
>>> Release+Notes#ReleaseNotes-Version1.2.0
>>>
>>> If anyone knows of anything that should be highlighted, feel free to
>>> mention it here and I can update the notes.
>>>
>>> Thanks!
>>>
>>> -Bryan
>>>
>>>
>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>
>>> Looks like we are down to just a few tickets, and all of them seem to
>>> have traction in terms of review and discussion.
>>>
>>> I'll keep an eye on the tickets and start trying to pull together
>>> anything I can to get ready for the RC process. Seems like we are
>>> close!
>>>
>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>>>
>>> russ@windofkeltia.com>
>>>
>>> wrote:
>>>
>>> Many thanks to all the industrious folk working on this tool that's
>>>
>>> become
>>>
>>> indispensable to so many. The community has my enduring gratitude and
>>> admiration!
>>>
>>> Russ
>>>
>>>
>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>
>>>
>>> Robert,
>>>
>>> We're about 10 or so JIRAs away at this point and all of them have
>>>
>>> PRs
>>>
>>> and progress on them.  We need to close those down and do some
>>> stabilization/testing then a release candidate can happen.  So
>>>
>>> perhaps
>>>
>>> next week we'll be at that point and have a release.  This is the
>>> right place to be watching to see it closing in.
>>>
>>> Thanks
>>> Joe
>>>
>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>
>>>
>>> Hi,
>>>
>>> is there any date set for 1.2.0 release yet?
>>> We are running into an  NIFI-3389
>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>>>
>>> would
>>>
>>> like
>>>
>>> to
>>> know when we can expect 1.2.0 release to be available.
>>>
>>> Thanks,
>>> Robert
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>>
>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>
>>> Sent from the Apache NiFi Developer List mailing list archive at
>>> Nabble.com.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> *Scott Aslan = new WebDeveloper(*
>>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>>  "zip": "34771"    },    "contact": {        "email":
>>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>>> "http://www.linkedin.com/in/scottyaslan
>>> <http://www.linkedin.com/in/scottaslan>"    }});*
>>>
>>>
>>>
>>>
>>>
>>>
>>
>

Re: Closing in on a NiFi 1.2.0 release?

[Andre <an...@fucs.org>]

All,

For some reason my canvas did not refresh after a process bounce (which
generally occurs) but reloading page allows for modifications.

Cheers

On Wed, May 3, 2017 at 7:43 AM, Andre <an...@fucs.org> wrote:

> folks,
>
> I was just working to debug the final thorns found reviewing NIFI-3726 and
> noticed an odd behavior and wanted to confirm.
>
> If I recall correctly in the past users could simply replace a processor
> NAR file and even if that NAR existed the flow would continue to work.
>
> I just replaced
>
> cp ~/nifi/nifi-nar-bundles/nifi-cybersecurity-bundle/nifi-
> cybersecurity-nar/target/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
> ~/devel/nifi-1.2.0-SNAPSHOT/lib/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
>
> (note the different ~/nifi ~/devel used to ensure I don't explode the rest
> of the already compiled components).
>
> When I try to make changes to the flow I am displayed with the following
> error:
>
> [image: Inline image 1]
>
> This happens even when I try to drag and drop connected processors around
> the canvas.
>
>
> Oddly enough I can still add and delete components to the canvas but
> whatever touches the tainted processor cannot be modified at all.
>
> Examples of messages:
>
> *Attempt to move*
>
> Component Position
> [5, cb0a31ac-015b-1000-7473-873a47eb702e, cb0a52ab-015b-1000-e43a-f6293a9ae99d]
> is not the most up-to-date revision. This component appears to have been
> modified
>
>
> *Attempt to delete a downstream processor*
> Error
> [1, cb0a31ac-015b-1000-7473-873a47eb702e, cb0b2ae4-015b-1000-35a8-9eaf6a45fc6a]
> is not the most up-to-date revision. This component appears to have been
> modified
>
>
> I don't have a 1.1.0 instance around me at the moment but I vaguely
> remember being able to do that in the past.
>
> Can someone confirm this is new and expected behavior?
>
> Cheers
>
>
> On Wed, May 3, 2017 at 5:54 AM, Andy LoPresto <al...@apache.org>
> wrote:
>
>> I’ll review & merge as soon as they are available.
>>
>> Andy LoPresto
>> alopresto@apache.org
>> *alopresto.apache@gmail.com <al...@gmail.com>*
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>> On May 2, 2017, at 3:51 PM, Bryan Bende <bb...@gmail.com> wrote:
>>
>> Thanks Drew. These seem like good candidates for the release.
>>
>> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <an...@gmail.com>
>> wrote:
>>
>> There are three doc updates/additions that would be great to include in
>> the RC:
>>
>> https://issues.apache.org/jira/browse/NIFI-3701
>> https://issues.apache.org/jira/browse/NIFI-3773
>> https://issues.apache.org/jira/browse/NIFI-3774
>>
>> Sarah Olson and I have been working on these.  We should have PRs
>> submitted for them very soon.
>>
>> -Drew
>>
>>
>> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
>>
>> Haven't had much luck in getting our Docker efforts incorporated into
>> Docker Hub.  As a result I have created an issue to track that integration
>> [1] and resolved the original issue.
>>
>> We can evaluate our options and figure out the best path forward.  At this
>> time procedures are not yet well established within ASF to support
>> configuring these builds.
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-3772
>>
>> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <an...@gmail.com>
>> wrote:
>>
>> I will be making updates to the Release Notes and Migration Guidance doc
>> regarding the TLS 1.2 version support.  Tracked by:
>>
>> https://issues.apache.org/jira/browse/NIFI-3720
>>
>>
>> -Drew
>>
>>
>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>>
>> Those are great updates.  I'd recommend we avoid highlighting the
>> versions of UI components though.
>>
>> Thanks
>>
>>
>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>>
>> wrote:
>>
>> Hey Bryan,
>>
>> Please include the following in the release notes:
>>
>>
>> - Core UI
>>    - Circular references have been removed and the code modularized.
>>    - Upgraded Node version to 6.9.3.
>>    - Upgraded npm version to 3.10.10.
>>    - Upgraded jQuery version to 3.1.1.
>>    - Upgraded D3 version to 3.5.17.
>>    - Reduced download size by removing bundled dependencies.
>> - User Experience Improvements
>> - Ever wish that it was easier to align components on the canvas? Me
>>    too...and now you can!
>>    - We now provide deep links to any component(s) on the canvas. This
>>    will help make collaborating and sharing more natural.
>>    - Users will enjoy a better understanding of the scope of
>>
>> Controller
>>
>>    Services through an improved experience.
>>    - All actions available on the operate palette are now also
>>
>> available
>>
>>    under the context menu too!
>>
>> Thanks!
>>
>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>>
>> All,
>>
>> Looks like we are closer than we have ever been!
>>
>> Down to three outstanding JIRAs...
>>
>> - NIFI-1833 (Azure Processors) - Active review and discussion
>> occurring, appears to be close
>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>> this may be moved from the release to a separate effort
>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>> like it could be merged relatively soon
>>
>> Once these are finalized we should be able to start the RC process.
>>
>> I've started putting together the release notes on the Wiki (still a
>> work in progress):
>> https://cwiki.apache.org/confluence/display/NIFI/
>> Release+Notes#ReleaseNotes-Version1.2.0
>>
>> If anyone knows of anything that should be highlighted, feel free to
>> mention it here and I can update the notes.
>>
>> Thanks!
>>
>> -Bryan
>>
>>
>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>
>> Looks like we are down to just a few tickets, and all of them seem to
>> have traction in terms of review and discussion.
>>
>> I'll keep an eye on the tickets and start trying to pull together
>> anything I can to get ready for the RC process. Seems like we are
>> close!
>>
>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>>
>> russ@windofkeltia.com>
>>
>> wrote:
>>
>> Many thanks to all the industrious folk working on this tool that's
>>
>> become
>>
>> indispensable to so many. The community has my enduring gratitude and
>> admiration!
>>
>> Russ
>>
>>
>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>
>>
>> Robert,
>>
>> We're about 10 or so JIRAs away at this point and all of them have
>>
>> PRs
>>
>> and progress on them.  We need to close those down and do some
>> stabilization/testing then a release candidate can happen.  So
>>
>> perhaps
>>
>> next week we'll be at that point and have a release.  This is the
>> right place to be watching to see it closing in.
>>
>> Thanks
>> Joe
>>
>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>
>>
>> Hi,
>>
>> is there any date set for 1.2.0 release yet?
>> We are running into an  NIFI-3389
>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>>
>> would
>>
>> like
>>
>> to
>> know when we can expect 1.2.0 release to be available.
>>
>> Thanks,
>> Robert
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>
>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>
>> Sent from the Apache NiFi Developer List mailing list archive at
>> Nabble.com.
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Scott Aslan = new WebDeveloper(*
>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>  "zip": "34771"    },    "contact": {        "email":
>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>> "http://www.linkedin.com/in/scottyaslan
>> <http://www.linkedin.com/in/scottaslan>"    }});*
>>
>>
>>
>>
>>
>>
>

Re: Closing in on a NiFi 1.2.0 release?

[Andre <an...@fucs.org>]

folks,

I was just working to debug the final thorns found reviewing NIFI-3726 and
noticed an odd behavior and wanted to confirm.

If I recall correctly in the past users could simply replace a processor
NAR file and even if that NAR existed the flow would continue to work.

I just replaced

cp
~/nifi/nifi-nar-bundles/nifi-cybersecurity-bundle/nifi-cybersecurity-nar/target/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar
~/devel/nifi-1.2.0-SNAPSHOT/lib/nifi-cybersecurity-nar-1.2.0-SNAPSHOT.nar

(note the different ~/nifi ~/devel used to ensure I don't explode the rest
of the already compiled components).

When I try to make changes to the flow I am displayed with the following
error:

[image: Inline image 1]

This happens even when I try to drag and drop connected processors around
the canvas.


Oddly enough I can still add and delete components to the canvas but
whatever touches the tainted processor cannot be modified at all.

Examples of messages:

*Attempt to move*

Component Position
[5, cb0a31ac-015b-1000-7473-873a47eb702e,
cb0a52ab-015b-1000-e43a-f6293a9ae99d] is not the most up-to-date revision.
This component appears to have been modified


*Attempt to delete a downstream processor*
Error
[1, cb0a31ac-015b-1000-7473-873a47eb702e,
cb0b2ae4-015b-1000-35a8-9eaf6a45fc6a] is not the most up-to-date revision.
This component appears to have been modified


I don't have a 1.1.0 instance around me at the moment but I vaguely
remember being able to do that in the past.

Can someone confirm this is new and expected behavior?

Cheers


On Wed, May 3, 2017 at 5:54 AM, Andy LoPresto <al...@apache.org> wrote:

> I’ll review & merge as soon as they are available.
>
> Andy LoPresto
> alopresto@apache.org
> *alopresto.apache@gmail.com <al...@gmail.com>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On May 2, 2017, at 3:51 PM, Bryan Bende <bb...@gmail.com> wrote:
>
> Thanks Drew. These seem like good candidates for the release.
>
> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <an...@gmail.com>
> wrote:
>
> There are three doc updates/additions that would be great to include in
> the RC:
>
> https://issues.apache.org/jira/browse/NIFI-3701
> https://issues.apache.org/jira/browse/NIFI-3773
> https://issues.apache.org/jira/browse/NIFI-3774
>
> Sarah Olson and I have been working on these.  We should have PRs
> submitted for them very soon.
>
> -Drew
>
>
> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
>
> Haven't had much luck in getting our Docker efforts incorporated into
> Docker Hub.  As a result I have created an issue to track that integration
> [1] and resolved the original issue.
>
> We can evaluate our options and figure out the best path forward.  At this
> time procedures are not yet well established within ASF to support
> configuring these builds.
>
> [1] https://issues.apache.org/jira/browse/NIFI-3772
>
> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <an...@gmail.com>
> wrote:
>
> I will be making updates to the Release Notes and Migration Guidance doc
> regarding the TLS 1.2 version support.  Tracked by:
>
> https://issues.apache.org/jira/browse/NIFI-3720
>
>
> -Drew
>
>
> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>
> Those are great updates.  I'd recommend we avoid highlighting the
> versions of UI components though.
>
> Thanks
>
>
> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>
> wrote:
>
> Hey Bryan,
>
> Please include the following in the release notes:
>
>
> - Core UI
>    - Circular references have been removed and the code modularized.
>    - Upgraded Node version to 6.9.3.
>    - Upgraded npm version to 3.10.10.
>    - Upgraded jQuery version to 3.1.1.
>    - Upgraded D3 version to 3.5.17.
>    - Reduced download size by removing bundled dependencies.
> - User Experience Improvements
> - Ever wish that it was easier to align components on the canvas? Me
>    too...and now you can!
>    - We now provide deep links to any component(s) on the canvas. This
>    will help make collaborating and sharing more natural.
>    - Users will enjoy a better understanding of the scope of
>
> Controller
>
>    Services through an improved experience.
>    - All actions available on the operate palette are now also
>
> available
>
>    under the context menu too!
>
> Thanks!
>
> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>
> All,
>
> Looks like we are closer than we have ever been!
>
> Down to three outstanding JIRAs...
>
> - NIFI-1833 (Azure Processors) - Active review and discussion
> occurring, appears to be close
> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
> this may be moved from the release to a separate effort
> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
> like it could be merged relatively soon
>
> Once these are finalized we should be able to start the RC process.
>
> I've started putting together the release notes on the Wiki (still a
> work in progress):
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version1.2.0
>
> If anyone knows of anything that should be highlighted, feel free to
> mention it here and I can update the notes.
>
> Thanks!
>
> -Bryan
>
>
> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>
> Looks like we are down to just a few tickets, and all of them seem to
> have traction in terms of review and discussion.
>
> I'll keep an eye on the tickets and start trying to pull together
> anything I can to get ready for the RC process. Seems like we are
> close!
>
> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>
> russ@windofkeltia.com>
>
> wrote:
>
> Many thanks to all the industrious folk working on this tool that's
>
> become
>
> indispensable to so many. The community has my enduring gratitude and
> admiration!
>
> Russ
>
>
> On 04/24/2017 07:16 PM, Joe Witt wrote:
>
>
> Robert,
>
> We're about 10 or so JIRAs away at this point and all of them have
>
> PRs
>
> and progress on them.  We need to close those down and do some
> stabilization/testing then a release candidate can happen.  So
>
> perhaps
>
> next week we'll be at that point and have a release.  This is the
> right place to be watching to see it closing in.
>
> Thanks
> Joe
>
> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>
>
> Hi,
>
> is there any date set for 1.2.0 release yet?
> We are running into an  NIFI-3389
> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>
> would
>
> like
>
> to
> know when we can expect 1.2.0 release to be available.
>
> Thanks,
> Robert
>
>
>
> --
> View this message in context:
> http://apache-nifi-developer-list.39713.n7.nabble.com/
>
> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>
> Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>
>
>
>
>
>
>
> --
> *Scott Aslan = new WebDeveloper(*
> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>  "zip": "34771"    },    "contact": {        "email":
> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
> "http://www.linkedin.com/in/scottyaslan
> <http://www.linkedin.com/in/scottaslan>"    }});*
>
>
>
>
>
>

Re: Closing in on a NiFi 1.2.0 release?

[Andy LoPresto <al...@apache.org>]

I’ll review & merge as soon as they are available.

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

> On May 2, 2017, at 3:51 PM, Bryan Bende <bb...@gmail.com> wrote:
> 
> Thanks Drew. These seem like good candidates for the release.
> 
> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <an...@gmail.com> wrote:
>> There are three doc updates/additions that would be great to include in the RC:
>> 
>> https://issues.apache.org/jira/browse/NIFI-3701
>> https://issues.apache.org/jira/browse/NIFI-3773
>> https://issues.apache.org/jira/browse/NIFI-3774
>> 
>> Sarah Olson and I have been working on these.  We should have PRs submitted for them very soon.
>> 
>> -Drew
>> 
>> 
>>> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
>>> 
>>> Haven't had much luck in getting our Docker efforts incorporated into
>>> Docker Hub.  As a result I have created an issue to track that integration
>>> [1] and resolved the original issue.
>>> 
>>> We can evaluate our options and figure out the best path forward.  At this
>>> time procedures are not yet well established within ASF to support
>>> configuring these builds.
>>> 
>>> [1] https://issues.apache.org/jira/browse/NIFI-3772
>>> 
>>> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <an...@gmail.com>
>>> wrote:
>>> 
>>>> I will be making updates to the Release Notes and Migration Guidance doc
>>>> regarding the TLS 1.2 version support.  Tracked by:
>>>> 
>>>> https://issues.apache.org/jira/browse/NIFI-3720
>>>> 
>>>> 
>>>> -Drew
>>>> 
>>>> 
>>>>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>>>>> 
>>>>> Those are great updates.  I'd recommend we avoid highlighting the
>>>>> versions of UI components though.
>>>>> 
>>>>> Thanks
>>>>> 
>>>>> 
>>>>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>>>> wrote:
>>>>>> Hey Bryan,
>>>>>> 
>>>>>> Please include the following in the release notes:
>>>>>> 
>>>>>> 
>>>>>> - Core UI
>>>>>>    - Circular references have been removed and the code modularized.
>>>>>>    - Upgraded Node version to 6.9.3.
>>>>>>    - Upgraded npm version to 3.10.10.
>>>>>>    - Upgraded jQuery version to 3.1.1.
>>>>>>    - Upgraded D3 version to 3.5.17.
>>>>>>    - Reduced download size by removing bundled dependencies.
>>>>>> - User Experience Improvements
>>>>>> - Ever wish that it was easier to align components on the canvas? Me
>>>>>>    too...and now you can!
>>>>>>    - We now provide deep links to any component(s) on the canvas. This
>>>>>>    will help make collaborating and sharing more natural.
>>>>>>    - Users will enjoy a better understanding of the scope of
>>>> Controller
>>>>>>    Services through an improved experience.
>>>>>>    - All actions available on the operate palette are now also
>>>> available
>>>>>>    under the context menu too!
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>> 
>>>>>>> All,
>>>>>>> 
>>>>>>> Looks like we are closer than we have ever been!
>>>>>>> 
>>>>>>> Down to three outstanding JIRAs...
>>>>>>> 
>>>>>>> - NIFI-1833 (Azure Processors) - Active review and discussion
>>>>>>> occurring, appears to be close
>>>>>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>>>>>>> this may be moved from the release to a separate effort
>>>>>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>>>>>>> like it could be merged relatively soon
>>>>>>> 
>>>>>>> Once these are finalized we should be able to start the RC process.
>>>>>>> 
>>>>>>> I've started putting together the release notes on the Wiki (still a
>>>>>>> work in progress):
>>>>>>> https://cwiki.apache.org/confluence/display/NIFI/
>>>>>>> Release+Notes#ReleaseNotes-Version1.2.0
>>>>>>> 
>>>>>>> If anyone knows of anything that should be highlighted, feel free to
>>>>>>> mention it here and I can update the notes.
>>>>>>> 
>>>>>>> Thanks!
>>>>>>> 
>>>>>>> -Bryan
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>>>> Looks like we are down to just a few tickets, and all of them seem to
>>>>>>>> have traction in terms of review and discussion.
>>>>>>>> 
>>>>>>>> I'll keep an eye on the tickets and start trying to pull together
>>>>>>>> anything I can to get ready for the RC process. Seems like we are
>>>>>>>> close!
>>>>>>>> 
>>>>>>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>>>> russ@windofkeltia.com>
>>>>>>> wrote:
>>>>>>>>> Many thanks to all the industrious folk working on this tool that's
>>>>>>> become
>>>>>>>>> indispensable to so many. The community has my enduring gratitude and
>>>>>>>>> admiration!
>>>>>>>>> 
>>>>>>>>> Russ
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>>>>>>>> 
>>>>>>>>>> Robert,
>>>>>>>>>> 
>>>>>>>>>> We're about 10 or so JIRAs away at this point and all of them have
>>>> PRs
>>>>>>>>>> and progress on them.  We need to close those down and do some
>>>>>>>>>> stabilization/testing then a release candidate can happen.  So
>>>> perhaps
>>>>>>>>>> next week we'll be at that point and have a release.  This is the
>>>>>>>>>> right place to be watching to see it closing in.
>>>>>>>>>> 
>>>>>>>>>> Thanks
>>>>>>>>>> Joe
>>>>>>>>>> 
>>>>>>>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> is there any date set for 1.2.0 release yet?
>>>>>>>>>>> We are running into an  NIFI-3389
>>>>>>>>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>>>> would
>>>>>>> like
>>>>>>>>>>> to
>>>>>>>>>>> know when we can expect 1.2.0 release to be available.
>>>>>>>>>>> 
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Robert
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>>>>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>>>>>>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>>>>>>>>> Nabble.com.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> *Scott Aslan = new WebDeveloper(*
>>>>>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>>>>>  "zip": "34771"    },    "contact": {        "email":
>>>>>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>>>>>> "http://www.linkedin.com/in/scottyaslan
>>>>>> <http://www.linkedin.com/in/scottaslan>"    }});*
>>>> 
>>>> 
>> 

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende <bb...@gmail.com>]

Thanks Drew. These seem like good candidates for the release.

On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <an...@gmail.com> wrote:
> There are three doc updates/additions that would be great to include in the RC:
>
> https://issues.apache.org/jira/browse/NIFI-3701
> https://issues.apache.org/jira/browse/NIFI-3773
> https://issues.apache.org/jira/browse/NIFI-3774
>
> Sarah Olson and I have been working on these.  We should have PRs submitted for them very soon.
>
> -Drew
>
>
>> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
>>
>> Haven't had much luck in getting our Docker efforts incorporated into
>> Docker Hub.  As a result I have created an issue to track that integration
>> [1] and resolved the original issue.
>>
>> We can evaluate our options and figure out the best path forward.  At this
>> time procedures are not yet well established within ASF to support
>> configuring these builds.
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-3772
>>
>> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <an...@gmail.com>
>> wrote:
>>
>>> I will be making updates to the Release Notes and Migration Guidance doc
>>> regarding the TLS 1.2 version support.  Tracked by:
>>>
>>> https://issues.apache.org/jira/browse/NIFI-3720
>>>
>>>
>>> -Drew
>>>
>>>
>>>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>>>>
>>>> Those are great updates.  I'd recommend we avoid highlighting the
>>>> versions of UI components though.
>>>>
>>>> Thanks
>>>>
>>>>
>>>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>>> wrote:
>>>>> Hey Bryan,
>>>>>
>>>>> Please include the following in the release notes:
>>>>>
>>>>>
>>>>>  - Core UI
>>>>>     - Circular references have been removed and the code modularized.
>>>>>     - Upgraded Node version to 6.9.3.
>>>>>     - Upgraded npm version to 3.10.10.
>>>>>     - Upgraded jQuery version to 3.1.1.
>>>>>     - Upgraded D3 version to 3.5.17.
>>>>>     - Reduced download size by removing bundled dependencies.
>>>>>  - User Experience Improvements
>>>>>  - Ever wish that it was easier to align components on the canvas? Me
>>>>>     too...and now you can!
>>>>>     - We now provide deep links to any component(s) on the canvas. This
>>>>>     will help make collaborating and sharing more natural.
>>>>>     - Users will enjoy a better understanding of the scope of
>>> Controller
>>>>>     Services through an improved experience.
>>>>>     - All actions available on the operate palette are now also
>>> available
>>>>>     under the context menu too!
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>
>>>>>> All,
>>>>>>
>>>>>> Looks like we are closer than we have ever been!
>>>>>>
>>>>>> Down to three outstanding JIRAs...
>>>>>>
>>>>>> - NIFI-1833 (Azure Processors) - Active review and discussion
>>>>>> occurring, appears to be close
>>>>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>>>>>> this may be moved from the release to a separate effort
>>>>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>>>>>> like it could be merged relatively soon
>>>>>>
>>>>>> Once these are finalized we should be able to start the RC process.
>>>>>>
>>>>>> I've started putting together the release notes on the Wiki (still a
>>>>>> work in progress):
>>>>>> https://cwiki.apache.org/confluence/display/NIFI/
>>>>>> Release+Notes#ReleaseNotes-Version1.2.0
>>>>>>
>>>>>> If anyone knows of anything that should be highlighted, feel free to
>>>>>> mention it here and I can update the notes.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> -Bryan
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>>> Looks like we are down to just a few tickets, and all of them seem to
>>>>>>> have traction in terms of review and discussion.
>>>>>>>
>>>>>>> I'll keep an eye on the tickets and start trying to pull together
>>>>>>> anything I can to get ready for the RC process. Seems like we are
>>>>>>> close!
>>>>>>>
>>>>>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>>> russ@windofkeltia.com>
>>>>>> wrote:
>>>>>>>> Many thanks to all the industrious folk working on this tool that's
>>>>>> become
>>>>>>>> indispensable to so many. The community has my enduring gratitude and
>>>>>>>> admiration!
>>>>>>>>
>>>>>>>> Russ
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>>>>>>>
>>>>>>>>> Robert,
>>>>>>>>>
>>>>>>>>> We're about 10 or so JIRAs away at this point and all of them have
>>> PRs
>>>>>>>>> and progress on them.  We need to close those down and do some
>>>>>>>>> stabilization/testing then a release candidate can happen.  So
>>> perhaps
>>>>>>>>> next week we'll be at that point and have a release.  This is the
>>>>>>>>> right place to be watching to see it closing in.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> is there any date set for 1.2.0 release yet?
>>>>>>>>>> We are running into an  NIFI-3389
>>>>>>>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>>> would
>>>>>> like
>>>>>>>>>> to
>>>>>>>>>> know when we can expect 1.2.0 release to be available.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Robert
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>>>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>>>>>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>>>>>>>> Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Scott Aslan = new WebDeveloper(*
>>>>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>>>>   "zip": "34771"    },    "contact": {        "email":
>>>>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>>>>> "http://www.linkedin.com/in/scottyaslan
>>>>> <http://www.linkedin.com/in/scottaslan>"    }});*
>>>
>>>
>

Re: Closing in on a NiFi 1.2.0 release?

[Andrew Lim <an...@gmail.com>]

There are three doc updates/additions that would be great to include in the RC:

https://issues.apache.org/jira/browse/NIFI-3701
https://issues.apache.org/jira/browse/NIFI-3773
https://issues.apache.org/jira/browse/NIFI-3774

Sarah Olson and I have been working on these.  We should have PRs submitted for them very soon.

-Drew


> On May 2, 2017, at 2:11 PM, Aldrin Piri <al...@gmail.com> wrote:
> 
> Haven't had much luck in getting our Docker efforts incorporated into
> Docker Hub.  As a result I have created an issue to track that integration
> [1] and resolved the original issue.
> 
> We can evaluate our options and figure out the best path forward.  At this
> time procedures are not yet well established within ASF to support
> configuring these builds.
> 
> [1] https://issues.apache.org/jira/browse/NIFI-3772
> 
> On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <an...@gmail.com>
> wrote:
> 
>> I will be making updates to the Release Notes and Migration Guidance doc
>> regarding the TLS 1.2 version support.  Tracked by:
>> 
>> https://issues.apache.org/jira/browse/NIFI-3720
>> 
>> 
>> -Drew
>> 
>> 
>>> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
>>> 
>>> Those are great updates.  I'd recommend we avoid highlighting the
>>> versions of UI components though.
>>> 
>>> Thanks
>>> 
>>> 
>>> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
>> wrote:
>>>> Hey Bryan,
>>>> 
>>>> Please include the following in the release notes:
>>>> 
>>>> 
>>>>  - Core UI
>>>>     - Circular references have been removed and the code modularized.
>>>>     - Upgraded Node version to 6.9.3.
>>>>     - Upgraded npm version to 3.10.10.
>>>>     - Upgraded jQuery version to 3.1.1.
>>>>     - Upgraded D3 version to 3.5.17.
>>>>     - Reduced download size by removing bundled dependencies.
>>>>  - User Experience Improvements
>>>>  - Ever wish that it was easier to align components on the canvas? Me
>>>>     too...and now you can!
>>>>     - We now provide deep links to any component(s) on the canvas. This
>>>>     will help make collaborating and sharing more natural.
>>>>     - Users will enjoy a better understanding of the scope of
>> Controller
>>>>     Services through an improved experience.
>>>>     - All actions available on the operate palette are now also
>> available
>>>>     under the context menu too!
>>>> 
>>>> Thanks!
>>>> 
>>>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>>>> 
>>>>> All,
>>>>> 
>>>>> Looks like we are closer than we have ever been!
>>>>> 
>>>>> Down to three outstanding JIRAs...
>>>>> 
>>>>> - NIFI-1833 (Azure Processors) - Active review and discussion
>>>>> occurring, appears to be close
>>>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>>>>> this may be moved from the release to a separate effort
>>>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>>>>> like it could be merged relatively soon
>>>>> 
>>>>> Once these are finalized we should be able to start the RC process.
>>>>> 
>>>>> I've started putting together the release notes on the Wiki (still a
>>>>> work in progress):
>>>>> https://cwiki.apache.org/confluence/display/NIFI/
>>>>> Release+Notes#ReleaseNotes-Version1.2.0
>>>>> 
>>>>> If anyone knows of anything that should be highlighted, feel free to
>>>>> mention it here and I can update the notes.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> -Bryan
>>>>> 
>>>>> 
>>>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>> Looks like we are down to just a few tickets, and all of them seem to
>>>>>> have traction in terms of review and discussion.
>>>>>> 
>>>>>> I'll keep an eye on the tickets and start trying to pull together
>>>>>> anything I can to get ready for the RC process. Seems like we are
>>>>>> close!
>>>>>> 
>>>>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
>> russ@windofkeltia.com>
>>>>> wrote:
>>>>>>> Many thanks to all the industrious folk working on this tool that's
>>>>> become
>>>>>>> indispensable to so many. The community has my enduring gratitude and
>>>>>>> admiration!
>>>>>>> 
>>>>>>> Russ
>>>>>>> 
>>>>>>> 
>>>>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>>>>>> 
>>>>>>>> Robert,
>>>>>>>> 
>>>>>>>> We're about 10 or so JIRAs away at this point and all of them have
>> PRs
>>>>>>>> and progress on them.  We need to close those down and do some
>>>>>>>> stabilization/testing then a release candidate can happen.  So
>> perhaps
>>>>>>>> next week we'll be at that point and have a release.  This is the
>>>>>>>> right place to be watching to see it closing in.
>>>>>>>> 
>>>>>>>> Thanks
>>>>>>>> Joe
>>>>>>>> 
>>>>>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> is there any date set for 1.2.0 release yet?
>>>>>>>>> We are running into an  NIFI-3389
>>>>>>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
>> would
>>>>> like
>>>>>>>>> to
>>>>>>>>> know when we can expect 1.2.0 release to be available.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Robert
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>>>>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>>>>>>> Nabble.com.
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> *Scott Aslan = new WebDeveloper(*
>>>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>>>   "zip": "34771"    },    "contact": {        "email":
>>>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>>>> "http://www.linkedin.com/in/scottyaslan
>>>> <http://www.linkedin.com/in/scottaslan>"    }});*
>> 
>> 

Re: Closing in on a NiFi 1.2.0 release?

[Aldrin Piri <al...@gmail.com>]

Haven't had much luck in getting our Docker efforts incorporated into
Docker Hub.  As a result I have created an issue to track that integration
[1] and resolved the original issue.

We can evaluate our options and figure out the best path forward.  At this
time procedures are not yet well established within ASF to support
configuring these builds.

[1] https://issues.apache.org/jira/browse/NIFI-3772

On Tue, May 2, 2017 at 11:13 AM, Andrew Lim <an...@gmail.com>
wrote:

> I will be making updates to the Release Notes and Migration Guidance doc
> regarding the TLS 1.2 version support.  Tracked by:
>
> https://issues.apache.org/jira/browse/NIFI-3720
>
>
> -Drew
>
>
> > On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
> >
> > Those are great updates.  I'd recommend we avoid highlighting the
> > versions of UI components though.
> >
> > Thanks
> >
> >
> > On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com>
> wrote:
> >> Hey Bryan,
> >>
> >> Please include the following in the release notes:
> >>
> >>
> >>   - Core UI
> >>      - Circular references have been removed and the code modularized.
> >>      - Upgraded Node version to 6.9.3.
> >>      - Upgraded npm version to 3.10.10.
> >>      - Upgraded jQuery version to 3.1.1.
> >>      - Upgraded D3 version to 3.5.17.
> >>      - Reduced download size by removing bundled dependencies.
> >>   - User Experience Improvements
> >>   - Ever wish that it was easier to align components on the canvas? Me
> >>      too...and now you can!
> >>      - We now provide deep links to any component(s) on the canvas. This
> >>      will help make collaborating and sharing more natural.
> >>      - Users will enjoy a better understanding of the scope of
> Controller
> >>      Services through an improved experience.
> >>      - All actions available on the operate palette are now also
> available
> >>      under the context menu too!
> >>
> >> Thanks!
> >>
> >> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
> >>
> >>> All,
> >>>
> >>> Looks like we are closer than we have ever been!
> >>>
> >>> Down to three outstanding JIRAs...
> >>>
> >>> - NIFI-1833 (Azure Processors) - Active review and discussion
> >>> occurring, appears to be close
> >>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
> >>> this may be moved from the release to a separate effort
> >>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
> >>> like it could be merged relatively soon
> >>>
> >>> Once these are finalized we should be able to start the RC process.
> >>>
> >>> I've started putting together the release notes on the Wiki (still a
> >>> work in progress):
> >>> https://cwiki.apache.org/confluence/display/NIFI/
> >>> Release+Notes#ReleaseNotes-Version1.2.0
> >>>
> >>> If anyone knows of anything that should be highlighted, feel free to
> >>> mention it here and I can update the notes.
> >>>
> >>> Thanks!
> >>>
> >>> -Bryan
> >>>
> >>>
> >>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
> >>>> Looks like we are down to just a few tickets, and all of them seem to
> >>>> have traction in terms of review and discussion.
> >>>>
> >>>> I'll keep an eye on the tickets and start trying to pull together
> >>>> anything I can to get ready for the RC process. Seems like we are
> >>>> close!
> >>>>
> >>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <
> russ@windofkeltia.com>
> >>> wrote:
> >>>>> Many thanks to all the industrious folk working on this tool that's
> >>> become
> >>>>> indispensable to so many. The community has my enduring gratitude and
> >>>>> admiration!
> >>>>>
> >>>>> Russ
> >>>>>
> >>>>>
> >>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
> >>>>>>
> >>>>>> Robert,
> >>>>>>
> >>>>>> We're about 10 or so JIRAs away at this point and all of them have
> PRs
> >>>>>> and progress on them.  We need to close those down and do some
> >>>>>> stabilization/testing then a release candidate can happen.  So
> perhaps
> >>>>>> next week we'll be at that point and have a release.  This is the
> >>>>>> right place to be watching to see it closing in.
> >>>>>>
> >>>>>> Thanks
> >>>>>> Joe
> >>>>>>
> >>>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> is there any date set for 1.2.0 release yet?
> >>>>>>> We are running into an  NIFI-3389
> >>>>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and
> would
> >>> like
> >>>>>>> to
> >>>>>>> know when we can expect 1.2.0 release to be available.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Robert
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> View this message in context:
> >>>>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
> >>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
> >>>>>>> Sent from the Apache NiFi Developer List mailing list archive at
> >>>>>>> Nabble.com.
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >>
> >> --
> >> *Scott Aslan = new WebDeveloper(*
> >> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
> >>    "zip": "34771"    },    "contact": {        "email":
> >> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
> >> "http://www.linkedin.com/in/scottyaslan
> >> <http://www.linkedin.com/in/scottaslan>"    }});*
>
>

Re: Closing in on a NiFi 1.2.0 release?

[Andrew Lim <an...@gmail.com>]

I will be making updates to the Release Notes and Migration Guidance doc regarding the TLS 1.2 version support.  Tracked by:

https://issues.apache.org/jira/browse/NIFI-3720


-Drew


> On May 2, 2017, at 11:08 AM, Joe Witt <jo...@gmail.com> wrote:
> 
> Those are great updates.  I'd recommend we avoid highlighting the
> versions of UI components though.
> 
> Thanks
> 
> 
> On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com> wrote:
>> Hey Bryan,
>> 
>> Please include the following in the release notes:
>> 
>> 
>>   - Core UI
>>      - Circular references have been removed and the code modularized.
>>      - Upgraded Node version to 6.9.3.
>>      - Upgraded npm version to 3.10.10.
>>      - Upgraded jQuery version to 3.1.1.
>>      - Upgraded D3 version to 3.5.17.
>>      - Reduced download size by removing bundled dependencies.
>>   - User Experience Improvements
>>   - Ever wish that it was easier to align components on the canvas? Me
>>      too...and now you can!
>>      - We now provide deep links to any component(s) on the canvas. This
>>      will help make collaborating and sharing more natural.
>>      - Users will enjoy a better understanding of the scope of Controller
>>      Services through an improved experience.
>>      - All actions available on the operate palette are now also available
>>      under the context menu too!
>> 
>> Thanks!
>> 
>> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>> 
>>> All,
>>> 
>>> Looks like we are closer than we have ever been!
>>> 
>>> Down to three outstanding JIRAs...
>>> 
>>> - NIFI-1833 (Azure Processors) - Active review and discussion
>>> occurring, appears to be close
>>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>>> this may be moved from the release to a separate effort
>>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>>> like it could be merged relatively soon
>>> 
>>> Once these are finalized we should be able to start the RC process.
>>> 
>>> I've started putting together the release notes on the Wiki (still a
>>> work in progress):
>>> https://cwiki.apache.org/confluence/display/NIFI/
>>> Release+Notes#ReleaseNotes-Version1.2.0
>>> 
>>> If anyone knows of anything that should be highlighted, feel free to
>>> mention it here and I can update the notes.
>>> 
>>> Thanks!
>>> 
>>> -Bryan
>>> 
>>> 
>>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>> Looks like we are down to just a few tickets, and all of them seem to
>>>> have traction in terms of review and discussion.
>>>> 
>>>> I'll keep an eye on the tickets and start trying to pull together
>>>> anything I can to get ready for the RC process. Seems like we are
>>>> close!
>>>> 
>>>> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <ru...@windofkeltia.com>
>>> wrote:
>>>>> Many thanks to all the industrious folk working on this tool that's
>>> become
>>>>> indispensable to so many. The community has my enduring gratitude and
>>>>> admiration!
>>>>> 
>>>>> Russ
>>>>> 
>>>>> 
>>>>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>>>> 
>>>>>> Robert,
>>>>>> 
>>>>>> We're about 10 or so JIRAs away at this point and all of them have PRs
>>>>>> and progress on them.  We need to close those down and do some
>>>>>> stabilization/testing then a release candidate can happen.  So perhaps
>>>>>> next week we'll be at that point and have a release.  This is the
>>>>>> right place to be watching to see it closing in.
>>>>>> 
>>>>>> Thanks
>>>>>> Joe
>>>>>> 
>>>>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> is there any date set for 1.2.0 release yet?
>>>>>>> We are running into an  NIFI-3389
>>>>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would
>>> like
>>>>>>> to
>>>>>>> know when we can expect 1.2.0 release to be available.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Robert
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>>>>> Nabble.com.
>>>>> 
>>>>> 
>>> 
>> 
>> 
>> 
>> --
>> *Scott Aslan = new WebDeveloper(*
>> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>>    "zip": "34771"    },    "contact": {        "email":
>> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
>> "http://www.linkedin.com/in/scottyaslan
>> <http://www.linkedin.com/in/scottaslan>"    }});*

Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt <jo...@gmail.com>]

Those are great updates.  I'd recommend we avoid highlighting the
versions of UI components though.

Thanks


On Tue, May 2, 2017 at 11:03 AM, Scott Aslan <sc...@gmail.com> wrote:
> Hey Bryan,
>
> Please include the following in the release notes:
>
>
>    - Core UI
>       - Circular references have been removed and the code modularized.
>       - Upgraded Node version to 6.9.3.
>       - Upgraded npm version to 3.10.10.
>       - Upgraded jQuery version to 3.1.1.
>       - Upgraded D3 version to 3.5.17.
>       - Reduced download size by removing bundled dependencies.
>    - User Experience Improvements
>    - Ever wish that it was easier to align components on the canvas? Me
>       too...and now you can!
>       - We now provide deep links to any component(s) on the canvas. This
>       will help make collaborating and sharing more natural.
>       - Users will enjoy a better understanding of the scope of Controller
>       Services through an improved experience.
>       - All actions available on the operate palette are now also available
>       under the context menu too!
>
> Thanks!
>
> On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:
>
>> All,
>>
>> Looks like we are closer than we have ever been!
>>
>> Down to three outstanding JIRAs...
>>
>> - NIFI-1833 (Azure Processors) - Active review and discussion
>> occurring, appears to be close
>> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
>> this may be moved from the release to a separate effort
>> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
>> like it could be merged relatively soon
>>
>> Once these are finalized we should be able to start the RC process.
>>
>> I've started putting together the release notes on the Wiki (still a
>> work in progress):
>> https://cwiki.apache.org/confluence/display/NIFI/
>> Release+Notes#ReleaseNotes-Version1.2.0
>>
>> If anyone knows of anything that should be highlighted, feel free to
>> mention it here and I can update the notes.
>>
>> Thanks!
>>
>> -Bryan
>>
>>
>> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
>> > Looks like we are down to just a few tickets, and all of them seem to
>> > have traction in terms of review and discussion.
>> >
>> > I'll keep an eye on the tickets and start trying to pull together
>> > anything I can to get ready for the RC process. Seems like we are
>> > close!
>> >
>> > On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <ru...@windofkeltia.com>
>> wrote:
>> >> Many thanks to all the industrious folk working on this tool that's
>> become
>> >> indispensable to so many. The community has my enduring gratitude and
>> >> admiration!
>> >>
>> >> Russ
>> >>
>> >>
>> >> On 04/24/2017 07:16 PM, Joe Witt wrote:
>> >>>
>> >>> Robert,
>> >>>
>> >>> We're about 10 or so JIRAs away at this point and all of them have PRs
>> >>> and progress on them.  We need to close those down and do some
>> >>> stabilization/testing then a release candidate can happen.  So perhaps
>> >>> next week we'll be at that point and have a release.  This is the
>> >>> right place to be watching to see it closing in.
>> >>>
>> >>> Thanks
>> >>> Joe
>> >>>
>> >>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>> >>>>
>> >>>> Hi,
>> >>>>
>> >>>> is there any date set for 1.2.0 release yet?
>> >>>> We are running into an  NIFI-3389
>> >>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would
>> like
>> >>>> to
>> >>>> know when we can expect 1.2.0 release to be available.
>> >>>>
>> >>>> Thanks,
>> >>>> Robert
>> >>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> View this message in context:
>> >>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
>> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>> >>>> Sent from the Apache NiFi Developer List mailing list archive at
>> >>>> Nabble.com.
>> >>
>> >>
>>
>
>
>
> --
> *Scott Aslan = new WebDeveloper(*
> *{    "location": {        "city": "Saint Cloud",        "state": "FL",
>     "zip": "34771"    },    "contact": {        "email":
> "scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
> "http://www.linkedin.com/in/scottyaslan
> <http://www.linkedin.com/in/scottaslan>"    }});*

Re: Closing in on a NiFi 1.2.0 release?

[Scott Aslan <sc...@gmail.com>]

Hey Bryan,

Please include the following in the release notes:


   - Core UI
      - Circular references have been removed and the code modularized.
      - Upgraded Node version to 6.9.3.
      - Upgraded npm version to 3.10.10.
      - Upgraded jQuery version to 3.1.1.
      - Upgraded D3 version to 3.5.17.
      - Reduced download size by removing bundled dependencies.
   - User Experience Improvements
   - Ever wish that it was easier to align components on the canvas? Me
      too...and now you can!
      - We now provide deep links to any component(s) on the canvas. This
      will help make collaborating and sharing more natural.
      - Users will enjoy a better understanding of the scope of Controller
      Services through an improved experience.
      - All actions available on the operate palette are now also available
      under the context menu too!

Thanks!

On Tue, May 2, 2017 at 10:17 AM, Bryan Bende <bb...@gmail.com> wrote:

> All,
>
> Looks like we are closer than we have ever been!
>
> Down to three outstanding JIRAs...
>
> - NIFI-1833 (Azure Processors) - Active review and discussion
> occurring, appears to be close
> - NIFI-3260 (Official Docker Image) - Active discussion, looks like
> this may be moved from the release to a separate effort
> - NIFI-3765 (Status operation for NodeManager) - Active review, looks
> like it could be merged relatively soon
>
> Once these are finalized we should be able to start the RC process.
>
> I've started putting together the release notes on the Wiki (still a
> work in progress):
> https://cwiki.apache.org/confluence/display/NIFI/
> Release+Notes#ReleaseNotes-Version1.2.0
>
> If anyone knows of anything that should be highlighted, feel free to
> mention it here and I can update the notes.
>
> Thanks!
>
> -Bryan
>
>
> On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
> > Looks like we are down to just a few tickets, and all of them seem to
> > have traction in terms of review and discussion.
> >
> > I'll keep an eye on the tickets and start trying to pull together
> > anything I can to get ready for the RC process. Seems like we are
> > close!
> >
> > On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <ru...@windofkeltia.com>
> wrote:
> >> Many thanks to all the industrious folk working on this tool that's
> become
> >> indispensable to so many. The community has my enduring gratitude and
> >> admiration!
> >>
> >> Russ
> >>
> >>
> >> On 04/24/2017 07:16 PM, Joe Witt wrote:
> >>>
> >>> Robert,
> >>>
> >>> We're about 10 or so JIRAs away at this point and all of them have PRs
> >>> and progress on them.  We need to close those down and do some
> >>> stabilization/testing then a release candidate can happen.  So perhaps
> >>> next week we'll be at that point and have a release.  This is the
> >>> right place to be watching to see it closing in.
> >>>
> >>> Thanks
> >>> Joe
> >>>
> >>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> is there any date set for 1.2.0 release yet?
> >>>> We are running into an  NIFI-3389
> >>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would
> like
> >>>> to
> >>>> know when we can expect 1.2.0 release to be available.
> >>>>
> >>>> Thanks,
> >>>> Robert
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> View this message in context:
> >>>> http://apache-nifi-developer-list.39713.n7.nabble.com/
> Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
> >>>> Sent from the Apache NiFi Developer List mailing list archive at
> >>>> Nabble.com.
> >>
> >>
>



-- 
*Scott Aslan = new WebDeveloper(*
*{    "location": {        "city": "Saint Cloud",        "state": "FL",
    "zip": "34771"    },    "contact": {        "email":
"scottyaslan@gmail.com <sc...@gmail.com>",        "linkedin":
"http://www.linkedin.com/in/scottyaslan
<http://www.linkedin.com/in/scottaslan>"    }});*

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende <bb...@gmail.com>]

All,

Looks like we are closer than we have ever been!

Down to three outstanding JIRAs...

- NIFI-1833 (Azure Processors) - Active review and discussion
occurring, appears to be close
- NIFI-3260 (Official Docker Image) - Active discussion, looks like
this may be moved from the release to a separate effort
- NIFI-3765 (Status operation for NodeManager) - Active review, looks
like it could be merged relatively soon

Once these are finalized we should be able to start the RC process.

I've started putting together the release notes on the Wiki (still a
work in progress):
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.2.0

If anyone knows of anything that should be highlighted, feel free to
mention it here and I can update the notes.

Thanks!

-Bryan


On Thu, Apr 27, 2017 at 5:52 PM, Bryan Bende <bb...@gmail.com> wrote:
> Looks like we are down to just a few tickets, and all of them seem to
> have traction in terms of review and discussion.
>
> I'll keep an eye on the tickets and start trying to pull together
> anything I can to get ready for the RC process. Seems like we are
> close!
>
> On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <ru...@windofkeltia.com> wrote:
>> Many thanks to all the industrious folk working on this tool that's become
>> indispensable to so many. The community has my enduring gratitude and
>> admiration!
>>
>> Russ
>>
>>
>> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>>
>>> Robert,
>>>
>>> We're about 10 or so JIRAs away at this point and all of them have PRs
>>> and progress on them.  We need to close those down and do some
>>> stabilization/testing then a release candidate can happen.  So perhaps
>>> next week we'll be at that point and have a release.  This is the
>>> right place to be watching to see it closing in.
>>>
>>> Thanks
>>> Joe
>>>
>>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> is there any date set for 1.2.0 release yet?
>>>> We are running into an  NIFI-3389
>>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would like
>>>> to
>>>> know when we can expect 1.2.0 release to be available.
>>>>
>>>> Thanks,
>>>> Robert
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://apache-nifi-developer-list.39713.n7.nabble.com/Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>>> Sent from the Apache NiFi Developer List mailing list archive at
>>>> Nabble.com.
>>
>>

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende <bb...@gmail.com>]

Looks like we are down to just a few tickets, and all of them seem to
have traction in terms of review and discussion.

I'll keep an eye on the tickets and start trying to pull together
anything I can to get ready for the RC process. Seems like we are
close!

On Tue, Apr 25, 2017 at 9:33 AM, Russell Bateman <ru...@windofkeltia.com> wrote:
> Many thanks to all the industrious folk working on this tool that's become
> indispensable to so many. The community has my enduring gratitude and
> admiration!
>
> Russ
>
>
> On 04/24/2017 07:16 PM, Joe Witt wrote:
>>
>> Robert,
>>
>> We're about 10 or so JIRAs away at this point and all of them have PRs
>> and progress on them.  We need to close those down and do some
>> stabilization/testing then a release candidate can happen.  So perhaps
>> next week we'll be at that point and have a release.  This is the
>> right place to be watching to see it closing in.
>>
>> Thanks
>> Joe
>>
>> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> is there any date set for 1.2.0 release yet?
>>> We are running into an  NIFI-3389
>>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would like
>>> to
>>> know when we can expect 1.2.0 release to be available.
>>>
>>> Thanks,
>>> Robert
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://apache-nifi-developer-list.39713.n7.nabble.com/Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>>> Sent from the Apache NiFi Developer List mailing list archive at
>>> Nabble.com.
>
>

Re: Closing in on a NiFi 1.2.0 release?

[Russell Bateman <ru...@windofkeltia.com>]

Many thanks to all the industrious folk working on this tool that's 
become indispensable to so many. The community has my enduring gratitude 
and admiration!

Russ

On 04/24/2017 07:16 PM, Joe Witt wrote:
> Robert,
>
> We're about 10 or so JIRAs away at this point and all of them have PRs
> and progress on them.  We need to close those down and do some
> stabilization/testing then a release candidate can happen.  So perhaps
> next week we'll be at that point and have a release.  This is the
> right place to be watching to see it closing in.
>
> Thanks
> Joe
>
> On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
>> Hi,
>>
>> is there any date set for 1.2.0 release yet?
>> We are running into an  NIFI-3389
>> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would like to
>> know when we can expect 1.2.0 release to be available.
>>
>> Thanks,
>> Robert
>>
>>
>>
>> --
>> View this message in context: http://apache-nifi-developer-list.39713.n7.nabble.com/Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
>> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt <jo...@gmail.com>]

Robert,

We're about 10 or so JIRAs away at this point and all of them have PRs
and progress on them.  We need to close those down and do some
stabilization/testing then a release candidate can happen.  So perhaps
next week we'll be at that point and have a release.  This is the
right place to be watching to see it closing in.

Thanks
Joe

On Mon, Apr 24, 2017 at 5:40 AM, roboh <he...@gmail.com> wrote:
> Hi,
>
> is there any date set for 1.2.0 release yet?
> We are running into an  NIFI-3389
> <https://issues.apache.org/jira/browse/NIFI-3389>   issue and would like to
> know when we can expect 1.2.0 release to be available.
>
> Thanks,
> Robert
>
>
>
> --
> View this message in context: http://apache-nifi-developer-list.39713.n7.nabble.com/Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Closing in on a NiFi 1.2.0 release?

[roboh <he...@gmail.com>]

Hi,

is there any date set for 1.2.0 release yet? 
We are running into an  NIFI-3389
<https://issues.apache.org/jira/browse/NIFI-3389>   issue and would like to
know when we can expect 1.2.0 release to be available. 

Thanks,
Robert



--
View this message in context: http://apache-nifi-developer-list.39713.n7.nabble.com/Closing-in-on-a-NiFi-1-2-0-release-tp14907p15532.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Closing in on a NiFi 1.2.0 release?

["Uwe@Moosheimer.com" <Uw...@Moosheimer.com>]

Twitter processor stays. Great news!
Thanks to Joey!

Mit freundlichen Grüßen / best regards
Kay-Uwe Moosheimer

> Am 11.04.2017 um 21:20 schrieb Joe Witt <jo...@gmail.com>:
> 
> Team,
> 
> Couple of good news updates on the release front is we're in the teens
> on number of tickets AND Joey Frazee figured out a way to clean up the
> twitter/json.org Cat-X dependency issue so our twitter processor
> stays!
> 
> Will keep working the march down to 0 tickets.  A lot of good stuff in
> this release so this should be a fun one!
> 
> Thanks
> Joe
> 
>> On Tue, Apr 4, 2017 at 7:37 PM, Tony Kurc <tr...@gmail.com> wrote:
>> Joe et. al,
>> I think this one is close too (mainly dotting i's and crossing t's on
>> license and notice)
>> 
>> https://issues.apache.org/jira/browse/NIFI-3586
>> 
>>> On Tue, Apr 4, 2017 at 2:23 PM, Joe Witt <jo...@gmail.com> wrote:
>>> 
>>> Team,
>>> 
>>> Another update on efforts to close-in on the NiFi 1.2.0 release.
>>> We're below 20 JIRAs now and there has been good momentum.  A couple
>>> items still need work but look really important and then there is
>>> review traction/feedback cycles.  Will just keep monitoring it and
>>> actively defending to close the loop on 1.2.0 until we're there.
>>> 
>>> Thanks
>>> Joe
>>> 
>>>> On Tue, Mar 28, 2017 at 9:45 AM, Joe Witt <jo...@gmail.com> wrote:
>>>> Team,
>>>> 
>>>> Status of JIRA cleanup toward an Apache NiFi 1.2.0 release candidate
>>>> which Mr Bende has so wonderfully volunteered to RM:
>>>> 
>>>> There are 20 open JIRAs as of now.
>>>> 
>>>> 12 of 20 have PRs that appear ready/close to ready.
>>>> 
>>>> One pattern I noticed quite a bit on the 1.2.0 release is heavy usage
>>>> of 'squatter JIRAs' whereby someone makes a JIRA and with or without
>>>> any review traction and for non blocking issues sets the fix version.
>>>> This practice should be avoided.  The fix version should be reserved
>>>> for once there is a blocker item or there is something with a patch
>>>> contributed and review progress closing in on a merge.
>>>> 
>>>> One of them means we need to punt the Twitter processor most likely.
>>>> Don't believe there were new releases to resolve that licensing issue
>>>> by the third party dependency.  I'll take that on.
>>>>  https://issues.apache.org/jira/browse/NIFI-3089
>>>> 
>>>> Two of them are build failure issues which means windows and linux
>>>> builds break (highly repeatable):
>>>>  https://issues.apache.org/jira/browse/NIFI-3441
>>>>  https://issues.apache.org/jira/browse/NIFI-3440
>>>> 
>>>> A couple need to either be moved out or addressed for implementation
>>>> or review but it isn't clear to me their status:
>>>>  https://issues.apache.org/jira/browse/NIFI-3155
>>>>  https://issues.apache.org/jira/browse/NIFI-1280
>>>>  https://issues.apache.org/jira/browse/NIFI-2656
>>>>  https://issues.apache.org/jira/browse/NIFI-2886
>>>> 
>>>> Some are really important and being worked still:
>>>>  https://issues.apache.org/jira/browse/NIFI-3520
>>>> 
>>>> Thanks
>>>> Joe
>>>> 
>>>>> On Wed, Mar 22, 2017 at 9:12 PM, Joe Witt <jo...@gmail.com> wrote:
>>>>> Sweet!  I'll take that deal all day.  Thanks Bryan!
>>>>> 
>>>>>> On Wed, Mar 22, 2017 at 8:26 PM, Bryan Bende <bb...@gmail.com> wrote:
>>>>>> Joe,
>>>>>> 
>>>>>> As of today I believe the PR for NIFI-3380 (component versioning)
>>> should
>>>>>> address all of the code review feedback and is in a good place.
>>>>>> 
>>>>>> Would like to run through a few more tests tomorrow, and baring any
>>>>>> additional feedback from reviewers, we could possibly merge that
>>> tomorrow.
>>>>>> That PR will also bump master to use the newly released NAR plugin.
>>>>>> 
>>>>>> Since I got a warm-up with NAR plugin, I don't mind taking on release
>>>>>> manager duties for 1.2, although I would still like help on the JIRA
>>>>>> whipping. I imagine there's still a bit of work to narrow down the
>>>>>> remaining tickets.
>>>>>> 
>>>>>> -Bryan
>>>>>> 
>>>>>>> On Wed, Mar 22, 2017 at 7:35 PM Joe Witt <jo...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Bryan
>>>>>>> 
>>>>>>> How are things looking for what you updated on?  The nar plugin of
>>>>>>> course is out.
>>>>>>> 
>>>>>>> We got another question on the user list for 1.2 so I just want to
>>>>>>> make sure we're closing in.  I'll start doing the JIRA whipping.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> JOe
>>>>>>> 
>>>>>>> On Mon, Mar 13, 2017 at 3:22 PM, Bryan Bende <bb...@gmail.com>
>>> wrote:
>>>>>>>> Just a quick update on this discussion...
>>>>>>>> 
>>>>>>>> On Friday we were able to post an initial PR for the component
>>>>>>>> versioning work [1].
>>>>>>>> 
>>>>>>>> I believe we are ready to move forward with a release of the NAR
>>> Maven
>>>>>>>> plugin, there are three tickets to be included in the release [2].
>>>>>>>> 
>>>>>>>> If there are no objections, I can take on the release manager duties
>>>>>>>> for the NAR plugin, and can begin to kick off the process tomorrow.
>>>>>>>> 
>>>>>>>> -Bryan
>>>>>>>> 
>>>>>>>> [1] https://github.com/apache/nifi/pull/1585
>>>>>>>> [2]
>>>>>>> https://issues.apache.org/jira/browse/NIFI-3589?jql=
>>> fixVersion%20%3D%20nifi-nar-maven-plugin-1.2.0%20AND%
>>> 20project%20%3D%20NIFI
>>>>>>>> 
>>>>>>>> On Wed, Mar 8, 2017 at 6:19 PM, James Wing <jv...@gmail.com>
>>> wrote:
>>>>>>>>> +1 for component versioning in 1.2.0, it will be a solid capstone
>>>>>>> feature.
>>>>>>>>> And I agree it's probably not holding up the release.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> 
>>>>>>>>> James
>>>>>>>>> 
>>>>>>>>> On Wed, Mar 8, 2017 at 1:21 PM, Bryan Bende <bb...@gmail.com>
>>> wrote:
>>>>>>>>> 
>>>>>>>>>> James,
>>>>>>>>>> 
>>>>>>>>>> No problem :)
>>>>>>>>>> 
>>>>>>>>>> I was mostly just suggesting an overall strategy...
>>>>>>>>>> 
>>>>>>>>>> Usually when we start closing in on a release we go through the
>>> JIRAs
>>>>>>>>>> tagged for that release and try to figure out which ones can be
>>> moved
>>>>>>>>>> to a future release, and which ones the community is actually
>>> working
>>>>>>>>>> on and close to being ready. Currently we have 39 unresolved JIRAs
>>>>>>>>>> that are tagged as 1.2, one of which is NIFI-3380, and I figured
>>> if
>>>>>>>>>> someone looked at the ticket it might look like no work had been
>>> done
>>>>>>>>>> and figure that it can just be moved to next release, so I just
>>> wanted
>>>>>>>>>> to mention that it is very close to being ready was still hoping
>>> for
>>>>>>>>>> it be in 1.2, unless there was strong opinion to move on without
>>> it.
>>>>>>>>>> Even if we moved on without it, I believe there is still a bit of
>>> work
>>>>>>>>>> to do in that we still need a release manager and we need to
>>> decide
>>>>>>>>>> what to do with the 39 JIRAs.
>>>>>>>>>> 
>>>>>>>>>> As far as the new NAR plugin and how things will work...
>>>>>>>>>> 
>>>>>>>>>> The changes to the NAR plugin add additional information to the
>>>>>>>>>> MANIFEST file in the NAR. Technically existing NiFi would have no
>>>>>>>>>> problem reading the new MANIFEST file because no entries are being
>>>>>>>>>> removed, and the branch I have with the component versioning code
>>> for
>>>>>>>>>> NiFi could also run against old NARs that don't have the new
>>> entries,
>>>>>>>>>> you just see everything as being "unversioned" and can't actually
>>> make
>>>>>>>>>> use of the new capabilities. We'll always have to be able to run
>>> older
>>>>>>>>>> NARs because there are tons of custom NARs out there that have not
>>>>>>>>>> been (and may never be) rebuilt with the newer version of the
>>> plugin,
>>>>>>>>>> which is fine, they only need to be rebuilt if someone wants to
>>> run
>>>>>>>>>> two versions of that NAR at the same time.
>>>>>>>>>> 
>>>>>>>>>> Happy to elaborate more on any of the component versioning work if
>>>>>>>>>> anyone is interested.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> 
>>>>>>>>>> Bryan
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Wed, Mar 8, 2017 at 2:43 PM, Russell Bateman <
>>> russ@windofkeltia.com
>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>> +1 for component versioning in NiFi 1.2!
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> On 03/08/2017 12:40 PM, James Wing wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Bryan, I'm 100% in favor of you and Matt Gilman doing all the
>>> hard
>>>>>>> work.
>>>>>>>>>>>> Oh, and uh... thanks! :)
>>>>>>>>>>>> 
>>>>>>>>>>>> So the alternatives are:
>>>>>>>>>>>> a.) Release 1.2.0 sooner (?), but without component versioning
>>>>>>>>>>>> b.) Delay 1.2.0 (?) to incorporate component versioning
>>>>>>>>>>>> 
>>>>>>>>>>>> Will the NAR plugin alone commit us to all of the component
>>>>>>> versioning
>>>>>>>>>>>> work
>>>>>>>>>>>> in 1.2, or will the new NAR format be backward-compatible?  Or
>>> is
>>>>>>> the
>>>>>>>>>>>> question more about the strategy for 1.2.0?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> 
>>>>>>>>>>>> James
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bb...@gmail.com>
>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Just wanted to mention that one of the JIRAs tagged for 1.2.0
>>> is
>>>>>>>>>>>>> NIFI-3380 "support multiple versions of the same component"
>>> [1] and
>>>>>>>>>>>>> I've been working with Matt Gilman on this [2]. The
>>> functionality
>>>>>>> is
>>>>>>>>>>>>> very close to being done and I think we should get this into
>>> the
>>>>>>> 1.2.0
>>>>>>>>>>>>> release.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> In order to fully leverage the versioned components we will
>>> need to
>>>>>>>>>>>>> release an updated Maven NAR plugin, so we would do that
>>> first and
>>>>>>>>>>>>> then release 1.2.0 using the new plugin. If everyone is
>>> on-board
>>>>>>> with
>>>>>>>>>>>>> this plan then I can advise when we are ready to release the
>>> new
>>>>>>>>>>>>> plugin which would be soon.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> [1] https://issues.apache.org/jira/browse/NIFI-3380
>>>>>>>>>>>>> [2] https://github.com/bbende/nifi/tree/NIFI-3380
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Fri, Mar 3, 2017 at 9:56 AM, Joe Gresock <
>>> jgresock@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> This is good discussion that should continue, but what about
>>> the
>>>>>>>>>>>>>> original
>>>>>>>>>>>>>> intent of Joe's post?  "Is there any reason folks can think
>>> of to
>>>>>>> hold
>>>>>>>>>>>>> 
>>>>>>>>>>>>> off
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> on a 1.2.0 release?"
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Mar 3, 2017 at 1:45 PM, Mark Payne <
>>> markap14@hotmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Andy,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Sorry, i haven't responded to this thread in over a week,
>>> but I
>>>>>>> think
>>>>>>>>>>>>> 
>>>>>>>>>>>>> it's
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> important to keep going.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I just clicked "Cancel Patch" on one of my ticket that has a
>>>>>>> patch
>>>>>>>>>>>>>>> available to see which state it returned to.
>>>>>>>>>>>>>>> It did in fact go back to Open. Which I agree is less than
>>> ideal.
>>>>>>>>>>>>>>> Though
>>>>>>>>>>>>>>> we could certainly have a process
>>>>>>>>>>>>>>> by which we change the status to "In Progress" after
>>> canceling
>>>>>>> the
>>>>>>>>>>>>> 
>>>>>>>>>>>>> patch.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I guess where my viewpoint differs from yours is in the
>>> meaning
>>>>>>> of
>>>>>>>>>> "In
>>>>>>>>>>>>>>> Review." Let's say that you submit a
>>>>>>>>>>>>>>> patch for a JIRA. I then review it and find that it needs
>>> some
>>>>>>> work -
>>>>>>>>>>>>>>> let's say there's an issue with licensing
>>>>>>>>>>>>>>> not being properly accounted for, for instance. At that
>>> point, I
>>>>>>> no
>>>>>>>>>>>>> 
>>>>>>>>>>>>> longer
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> consider the patch that you provided
>>>>>>>>>>>>>>> to be "In Review." I believe the patch should be canceled,
>>> and
>>>>>>> you
>>>>>>>>>> will
>>>>>>>>>>>>>>> need to submit a new patch. I guess
>>>>>>>>>>>>>>> that I view a patch as being an immutable entity.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 24, 2017, at 7:26 PM, Andy LoPresto <
>>> alopresto@apache.org
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <mailto:a
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> lopresto@apache.org>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Mark,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Your understanding of “Patch Available” certainly makes
>>> sense
>>>>>>> and it
>>>>>>>>>>>>>>> explains why you approach the process the way you do. I
>>> have a
>>>>>>>>>> slightly
>>>>>>>>>>>>>>> different personal understanding of “Patch Available” — I
>>> read
>>>>>>> it to
>>>>>>>>>>>>> 
>>>>>>>>>>>>> mean
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> “the person responsible for this Jira has contributed code
>>> they
>>>>>>> feel
>>>>>>>>>>>>> 
>>>>>>>>>>>>> solves
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> the issue.” A review will (hopefully) determine if that
>>>>>>> assertion is
>>>>>>>>>>>>>>> correct and complete. I think we kind of agree on "my
>>> viewpoint
>>>>>>> is
>>>>>>>>>>>>> 
>>>>>>>>>>>>> simply
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> that "Patch Available" means "Awaiting Review" or "In
>>> Review.””
>>>>>>> but I
>>>>>>>>>>>>> 
>>>>>>>>>>>>> see
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> “In Review” as a potentially iterative process — it could
>>> be on
>>>>>>> the
>>>>>>>>>>>>> 
>>>>>>>>>>>>> second
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> pass of the contributor responding to comments, but it’s
>>> still
>>>>>>> “In
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Review”
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> in my eyes. I don’t know that the granularity of Jira
>>> supports
>>>>>>> the
>>>>>>>>>>>>> 
>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> workflow states of “been reviewed once but not
>>> complete/accepted
>>>>>>>>>> yet”.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> What state does “Cancel Patch” result in? If it just
>>> reverts to
>>>>>>>>>> “Open”,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> don’t see the value because that obfuscates the difference
>>>>>>> between a
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Jira
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> that hasn’t even been touched and one that has 90% of the
>>> code
>>>>>>> done.
>>>>>>>>>> I
>>>>>>>>>>>>>>> agree we should make the RM’s job easier, but I also think
>>> it
>>>>>>> doesn’t
>>>>>>>>>>>>> 
>>>>>>>>>>>>> help
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> the visibility for reviewers to see a Jira marked as “open”
>>> when
>>>>>>>>>> there
>>>>>>>>>>>>> 
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> the potential for that patch to be ready for merge in a very
>>>>>>> short
>>>>>>>>>>>>> 
>>>>>>>>>>>>> amount
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> of time.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I think these conversations will ultimately help us narrow
>>> in on
>>>>>>>>>> shared
>>>>>>>>>>>>>>> definitions that make sense to everyone though, so I’m glad
>>> we’re
>>>>>>>>>>>>> 
>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> about it.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Andy LoPresto
>>>>>>>>>>>>>>> alopresto@apache.org<ma...@apache.org>
>>>>>>>>>>>>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
>>> com>
>>>>>>>>>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
>>> 2F7D
>>>>>>> EF69
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <
>>> markap14@hotmail.com
>>>>>>>>>> <mailto:m
>>>>>>>>>>>>>>> arkap14@hotmail.com>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Andy,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If the reviewer is looking for clarification, then it may
>>> make
>>>>>>> sense
>>>>>>>>>> to
>>>>>>>>>>>>>>> leave the JIRA in "Patch Available" state
>>>>>>>>>>>>>>> as you suggest. If there are minor fixes needed, though,
>>> then the
>>>>>>>>>> patch
>>>>>>>>>>>>> 
>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> not ready. In JIRA, the verbiage for
>>>>>>>>>>>>>>> Cancel Patch says "The patch is not yet ready to be
>>> committed."
>>>>>>> So if
>>>>>>>>>>>>>>> minor fixes are needed, then I believe
>>>>>>>>>>>>>>> it is appropriate to Cancel Patch. Once those changes
>>> (minor or
>>>>>>> not)
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> made and the PR updated, then the
>>>>>>>>>>>>>>> PR needs review again and the status should be changed back
>>> to
>>>>>>> "Patch
>>>>>>>>>>>>>>> Available" again.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I guess my viewpoint is simply that "Patch Available" means
>>>>>>> "Awaiting
>>>>>>>>>>>>>>> Review" or "In Review." If it is awaiting
>>>>>>>>>>>>>>> changes of some kind and won't be merged as-is, then we
>>> should
>>>>>>> Cancel
>>>>>>>>>>>>>>> Patch.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Do you or others have differing views on the meaning of
>>> "Patch
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Available"?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> -Mark
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 24, 2017, at 3:27 PM, Andy LoPresto <
>>> alopresto@apache.org
>>>>>>>>>>>>> 
>>>>>>>>>>>>> <mailto:a
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> lopresto@apache.org><ma...@apache.org>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Mark,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I like your point about updating the Jira with the Fix
>>> Version
>>>>>>> at the
>>>>>>>>>>>>> 
>>>>>>>>>>>>> time
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> the PR review begins (or when the PR is submitted, if the
>>>>>>> contributor
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> aware of this process). I think it’s better than waiting
>>> for the
>>>>>>>>>> merge,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> as
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I proposed before.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I agree that the reviewer is responsible for keeping the
>>> Jira
>>>>>>> updated
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> line with their work. I don’t know if I am on the same page
>>> as
>>>>>>> you
>>>>>>>>>> for
>>>>>>>>>>>>>>> “Cancel Patch” if the PR needs changes; sometimes these are
>>> minor
>>>>>>>>>> fixes
>>>>>>>>>>>>> 
>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> just looking for clarification from the contributor, and I
>>> don’t
>>>>>>>>>> think
>>>>>>>>>>>>> 
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> warrants canceling the availability of the patch. If they
>>> are
>>>>>>> major
>>>>>>>>>>>>>>> architectural changes, then that makes more sense to me.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Andy LoPresto
>>>>>>>>>>>>>>> alopresto@apache.org<ma...@apache.org><mailto:
>>> alo
>>>>>>>>>>>>>>> presto@apache.org>
>>>>>>>>>>>>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
>>> com
>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>> alopresto.apache@gmail.com>
>>>>>>>>>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
>>> 2F7D
>>>>>>> EF69
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <
>>> markap14@hotmail.com
>>>>>>>>>> <mailto:m
>>>>>>>>>>>>>>> arkap14@hotmail.com><ma...@hotmail.com>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Personally, I am afraid that if we don't set a Fix Version
>>> on
>>>>>>> JIRA's,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> some PR's will be lost
>>>>>>>>>>>>>>> or stalled. I rarely go to github and start looking through
>>> the
>>>>>>> PRs.
>>>>>>>>>>>>>>> Instead, I go to JIRA and look
>>>>>>>>>>>>>>> at what is assigned with a fixVersion of the next release.
>>> Then
>>>>>>> I'll
>>>>>>>>>> go
>>>>>>>>>>>>>>> and review JIRA's that are
>>>>>>>>>>>>>>> in a state of "Patch Available." Even then I often come
>>> across
>>>>>>> many
>>>>>>>>>>>>>>> PR's
>>>>>>>>>>>>>>> that have already been
>>>>>>>>>>>>>>> reviewed by one or more other committers and are awaiting
>>>>>>> updates.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> So I propose that we address this slightly differently. I
>>> believe
>>>>>>>>>> that
>>>>>>>>>>>>> 
>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> should assign a Fix Version to
>>>>>>>>>>>>>>> a JIRA whenever a PR is submitted. Then, whenever a
>>> committer
>>>>>>>>>> reviews a
>>>>>>>>>>>>>>> PR, he/she should be
>>>>>>>>>>>>>>> responsible for updating the JIRA. If the PR is merged then
>>> the
>>>>>>> JIRA
>>>>>>>>>>>>>>> should be resolved as Fixed.
>>>>>>>>>>>>>>> But if the PR is not merged because some changes are
>>> needed, the
>>>>>>>>>>>>> 
>>>>>>>>>>>>> reviewer
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> should then go back to
>>>>>>>>>>>>>>> the JIRA and click 'Cancel Patch'. We are typically very
>>> good
>>>>>>> about
>>>>>>>>>>>>>>> resolving as fixed once a PR is
>>>>>>>>>>>>>>> merged, but we don't typically cancel the patch otherwise.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> If we followed this workflow, then a Release Manager (or
>>> anyone
>>>>>>> else)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> can
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> easily see which tickets
>>>>>>>>>>>>>>> need to be reviewed before a release happens and which ones
>>> can
>>>>>>> be
>>>>>>>>>>>>> 
>>>>>>>>>>>>> pushed
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> out because they
>>>>>>>>>>>>>>> are not ready (even if a PR has been posted). It also makes
>>> it
>>>>>>> much
>>>>>>>>>>>>> 
>>>>>>>>>>>>> easier
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> for reviewers to quickly
>>>>>>>>>>>>>>> know which tickets are awaiting review.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thoughts?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -Mark
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 23, 2017, at 3:37 AM, Andy LoPresto <
>>>>>>>>>> alopresto.apache@gmail.com<
>>>>>>>>>>>>>>> mailto:alopresto.apache@gmail.com><mailto:
>>>>>>> alopresto.apache@gmail.com
>>>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> As someone who has surely been guilty of optimistically
>>> setting
>>>>>>> fix
>>>>>>>>>>>>>>> versions and then not meeting them, I second Joe's point
>>> about it
>>>>>>>>>>>>> 
>>>>>>>>>>>>> holding
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> up releases. Better to get the PR out, reviewed, and merged
>>>>>>> *before*
>>>>>>>>>>>>>>> setting the fix version in my opinion.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Andy LoPresto
>>>>>>>>>>>>>>> alopresto@apache.org<ma...@apache.org><mailto:
>>> alo
>>>>>>>>>>>>>>> presto@apache.org>
>>>>>>>>>>>>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
>>> com
>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>> alopresto.apache@gmail.com>
>>>>>>>>>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
>>> 2F7D
>>>>>>> EF69
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.witt@gmail.com
>>> <mailto:
>>>>>>> joe
>>>>>>>>>>>>>>> .witt@gmail.com>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Peter,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> This is just my preference so discussion is certainly
>>> open.  But
>>>>>>> the
>>>>>>>>>>>>>>> way I see it we should not set the fix version on JIRAs
>>> unless
>>>>>>> they
>>>>>>>>>>>>>>> really should block a release without resolution or if due
>>> to
>>>>>>> some
>>>>>>>>>>>>>>> roadmap/planning/discussion it is a new feature/improvement
>>> that
>>>>>>> is
>>>>>>>>>>>>>>> tied to a release.  Otherwise, for the many things which
>>> pop up
>>>>>>>>>>>>>>> throughout a given release cycle they should be avoided.
>>> That
>>>>>>> is to
>>>>>>>>>>>>>>> say the majority of the time we'd avoid fix versions until
>>> the
>>>>>>> act of
>>>>>>>>>>>>>>> merging a contribution which also means it has been
>>> reviewed.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> From the release management point of view:
>>>>>>>>>>>>>>> This approach helps greatly as until now it is has been
>>> really
>>>>>>>>>>>>>>> difficult and time consuming to pull together/close down a
>>>>>>> release as
>>>>>>>>>>>>>>> pretty much anyone can set these fix versions and make it
>>> appear
>>>>>>> as
>>>>>>>>>>>>>>> though the release is not ready when in reality it is
>>> perfectly
>>>>>>>>>>>>>>> releasable as-is but might miss out on some contribs that
>>> someone
>>>>>>>>>>>>>>> would like to see in the release but has as of yet not
>>> gotten
>>>>>>> the PR
>>>>>>>>>>>>>>> and/or review traction necessary.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> From the contributor point of view:
>>>>>>>>>>>>>>> If someone makes a contribution they obviously want that
>>> code to
>>>>>>> end
>>>>>>>>>>>>>>> up in a release.  But being an RTC community we need and
>>> want
>>>>>>> peer
>>>>>>>>>>>>>>> review before the code is submitted.  Some contributions are
>>>>>>> frankly
>>>>>>>>>>>>>>> hard to get peer review on or simply take time for someone
>>> to
>>>>>>>>>>>>>>> volunteer to do.  PRs which are difficult to test, lack
>>> testing,
>>>>>>> are
>>>>>>>>>>>>>>> related to systems or environments which are not easily
>>>>>>> replicated,
>>>>>>>>>>>>>>> etc.. are inherently harder to get peer review for.  Also,
>>> the
>>>>>>>>>>>>>>> community has grown quite rapidly and sometimes the hygiene
>>> of a
>>>>>>>>>> given
>>>>>>>>>>>>>>> PR isn't great.  So our 'patch available' and 'open PR'
>>> count
>>>>>>> ticks
>>>>>>>>>>>>>>> up.  We need reviews/feedback as much as we need
>>> contributions
>>>>>>> so it
>>>>>>>>>>>>>>> is important for folks that want those contributions in to
>>> build
>>>>>>>>>>>>>>> meritocracy as well in reviewing others contributions.  This
>>>>>>> helps
>>>>>>>>>>>>>>> build a network of contributors/reviewers and improves the
>>>>>>> timeliness
>>>>>>>>>>>>>>> of reviews.  Long story short here is that because at times
>>> PRs
>>>>>>> can
>>>>>>>>>>>>>>> sit too long sometimes people put a fix version on the JIRA
>>> so it
>>>>>>>>>> acts
>>>>>>>>>>>>>>> as a sort of 'gating function' on the release.  This I am
>>> saying
>>>>>>> is
>>>>>>>>>>>>>>> the practice that should not occur (given the thoughts
>>> above).
>>>>>>> We
>>>>>>>>>>>>>>> should instead take the issue of how to more effectively
>>>>>>>>>>>>>>> triage/review/provide feedback/and manage expectations for
>>>>>>>>>>>>>>> contributions so contributors don't feel like their stuff
>>> will
>>>>>>> just
>>>>>>>>>>>>>>> sit forever.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Does that make sense and seem fair?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) <
>>>>>>>>>>>>> 
>>>>>>>>>>>>> pwicks@micron.com
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> <ma...@micron.com>> wrote:
>>>>>>>>>>>>>>> Just for clarification, "We really need to avoid the
>>> practice of
>>>>>>>>>>>>>>> setting
>>>>>>>>>>>>>>> fix versions without traction", would mean don't set a
>>> version
>>>>>>> number
>>>>>>>>>>>>> 
>>>>>>>>>>>>> until
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> after we've submitted a PR? Until after the PR has been
>>> closed?
>>>>>>>>>> Other?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Peter
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Joe Witt [mailto:joe.witt@gmail.com]
>>>>>>>>>>>>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>>>>>>>>>>>>>> To: dev@nifi.apache.org<ma...@nifi.apache.org>
>>>>>>>>>>>>>>> Subject: Closing in on a NiFi 1.2.0 release?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> team,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On the users lists we had an ask of when we are planning to
>>> cut a
>>>>>>>>>>>>>>> 1.2.0 release.  And someone else asked me recently off-list.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> There are 45 open JIRAs tagged to it as of now.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%
>>>>>>>>>>>>>>> 
>>>>>>> 3D%20NIFI%20AND%20fixVersion%20%3D%201.2.0%20AND%20resolution%20%3D%
>>>>>>>>>>>>>>> 20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'd be favorable to going through and seeing if we can
>>> start the
>>>>>>>>>>>>>>> motions
>>>>>>>>>>>>>>> for a 1.2.0 release and which are ones we can wait for and
>>> which
>>>>>>> we
>>>>>>>>>>>>> 
>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> have in 1.2.0 for sure.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Is there any reason folks can think of to hold off on a
>>> 1.2.0
>>>>>>>>>> release?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> A non trivial number of the JIRAs are for things which have
>>> or
>>>>>>> do not
>>>>>>>>>>>>> 
>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> PRs but have no review traction.  We really need to avoid
>>> the
>>>>>>>>>> practice
>>>>>>>>>>>>> 
>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> setting fix versions without traction on this as otherwise
>>> it
>>>>>>> holds
>>>>>>>>>> up
>>>>>>>>>>>>> 
>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> releases.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> I know what it is to be in need, and I know what it is to
>>> have
>>>>>>> plenty.
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> have learned the secret of being content in any and every
>>>>>>> situation,
>>>>>>>>>>>>>> whether well fed or hungry, whether living in plenty or in
>>> want.
>>>>>>> I
>>>>>>>>>> can
>>>>>>>>>>>>> 
>>>>>>>>>>>>> do
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> all this through him who gives me strength.    *-Philippians
>>>>>>> 4:12-13*
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>>> --
>>>>>> Sent from Gmail Mobile
>>> 

Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt <jo...@gmail.com>]

Team,

Couple of good news updates on the release front is we're in the teens
on number of tickets AND Joey Frazee figured out a way to clean up the
twitter/json.org Cat-X dependency issue so our twitter processor
stays!

Will keep working the march down to 0 tickets.  A lot of good stuff in
this release so this should be a fun one!

Thanks
Joe

On Tue, Apr 4, 2017 at 7:37 PM, Tony Kurc <tr...@gmail.com> wrote:
> Joe et. al,
> I think this one is close too (mainly dotting i's and crossing t's on
> license and notice)
>
> https://issues.apache.org/jira/browse/NIFI-3586
>
> On Tue, Apr 4, 2017 at 2:23 PM, Joe Witt <jo...@gmail.com> wrote:
>
>> Team,
>>
>> Another update on efforts to close-in on the NiFi 1.2.0 release.
>> We're below 20 JIRAs now and there has been good momentum.  A couple
>> items still need work but look really important and then there is
>> review traction/feedback cycles.  Will just keep monitoring it and
>> actively defending to close the loop on 1.2.0 until we're there.
>>
>> Thanks
>> Joe
>>
>> On Tue, Mar 28, 2017 at 9:45 AM, Joe Witt <jo...@gmail.com> wrote:
>> > Team,
>> >
>> > Status of JIRA cleanup toward an Apache NiFi 1.2.0 release candidate
>> > which Mr Bende has so wonderfully volunteered to RM:
>> >
>> > There are 20 open JIRAs as of now.
>> >
>> > 12 of 20 have PRs that appear ready/close to ready.
>> >
>> > One pattern I noticed quite a bit on the 1.2.0 release is heavy usage
>> > of 'squatter JIRAs' whereby someone makes a JIRA and with or without
>> > any review traction and for non blocking issues sets the fix version.
>> > This practice should be avoided.  The fix version should be reserved
>> > for once there is a blocker item or there is something with a patch
>> > contributed and review progress closing in on a merge.
>> >
>> > One of them means we need to punt the Twitter processor most likely.
>> > Don't believe there were new releases to resolve that licensing issue
>> > by the third party dependency.  I'll take that on.
>> >   https://issues.apache.org/jira/browse/NIFI-3089
>> >
>> > Two of them are build failure issues which means windows and linux
>> > builds break (highly repeatable):
>> >   https://issues.apache.org/jira/browse/NIFI-3441
>> >   https://issues.apache.org/jira/browse/NIFI-3440
>> >
>> > A couple need to either be moved out or addressed for implementation
>> > or review but it isn't clear to me their status:
>> >   https://issues.apache.org/jira/browse/NIFI-3155
>> >   https://issues.apache.org/jira/browse/NIFI-1280
>> >   https://issues.apache.org/jira/browse/NIFI-2656
>> >   https://issues.apache.org/jira/browse/NIFI-2886
>> >
>> > Some are really important and being worked still:
>> >   https://issues.apache.org/jira/browse/NIFI-3520
>> >
>> > Thanks
>> > Joe
>> >
>> > On Wed, Mar 22, 2017 at 9:12 PM, Joe Witt <jo...@gmail.com> wrote:
>> >> Sweet!  I'll take that deal all day.  Thanks Bryan!
>> >>
>> >> On Wed, Mar 22, 2017 at 8:26 PM, Bryan Bende <bb...@gmail.com> wrote:
>> >>> Joe,
>> >>>
>> >>> As of today I believe the PR for NIFI-3380 (component versioning)
>> should
>> >>> address all of the code review feedback and is in a good place.
>> >>>
>> >>> Would like to run through a few more tests tomorrow, and baring any
>> >>> additional feedback from reviewers, we could possibly merge that
>> tomorrow.
>> >>> That PR will also bump master to use the newly released NAR plugin.
>> >>>
>> >>> Since I got a warm-up with NAR plugin, I don't mind taking on release
>> >>> manager duties for 1.2, although I would still like help on the JIRA
>> >>> whipping. I imagine there's still a bit of work to narrow down the
>> >>> remaining tickets.
>> >>>
>> >>> -Bryan
>> >>>
>> >>> On Wed, Mar 22, 2017 at 7:35 PM Joe Witt <jo...@gmail.com> wrote:
>> >>>
>> >>>> Bryan
>> >>>>
>> >>>> How are things looking for what you updated on?  The nar plugin of
>> >>>> course is out.
>> >>>>
>> >>>> We got another question on the user list for 1.2 so I just want to
>> >>>> make sure we're closing in.  I'll start doing the JIRA whipping.
>> >>>>
>> >>>> Thanks
>> >>>> JOe
>> >>>>
>> >>>> On Mon, Mar 13, 2017 at 3:22 PM, Bryan Bende <bb...@gmail.com>
>> wrote:
>> >>>> > Just a quick update on this discussion...
>> >>>> >
>> >>>> > On Friday we were able to post an initial PR for the component
>> >>>> > versioning work [1].
>> >>>> >
>> >>>> > I believe we are ready to move forward with a release of the NAR
>> Maven
>> >>>> > plugin, there are three tickets to be included in the release [2].
>> >>>> >
>> >>>> > If there are no objections, I can take on the release manager duties
>> >>>> > for the NAR plugin, and can begin to kick off the process tomorrow.
>> >>>> >
>> >>>> > -Bryan
>> >>>> >
>> >>>> > [1] https://github.com/apache/nifi/pull/1585
>> >>>> > [2]
>> >>>> https://issues.apache.org/jira/browse/NIFI-3589?jql=
>> fixVersion%20%3D%20nifi-nar-maven-plugin-1.2.0%20AND%
>> 20project%20%3D%20NIFI
>> >>>> >
>> >>>> > On Wed, Mar 8, 2017 at 6:19 PM, James Wing <jv...@gmail.com>
>> wrote:
>> >>>> >> +1 for component versioning in 1.2.0, it will be a solid capstone
>> >>>> feature.
>> >>>> >> And I agree it's probably not holding up the release.
>> >>>> >>
>> >>>> >> Thanks,
>> >>>> >>
>> >>>> >> James
>> >>>> >>
>> >>>> >> On Wed, Mar 8, 2017 at 1:21 PM, Bryan Bende <bb...@gmail.com>
>> wrote:
>> >>>> >>
>> >>>> >>> James,
>> >>>> >>>
>> >>>> >>> No problem :)
>> >>>> >>>
>> >>>> >>> I was mostly just suggesting an overall strategy...
>> >>>> >>>
>> >>>> >>> Usually when we start closing in on a release we go through the
>> JIRAs
>> >>>> >>> tagged for that release and try to figure out which ones can be
>> moved
>> >>>> >>> to a future release, and which ones the community is actually
>> working
>> >>>> >>> on and close to being ready. Currently we have 39 unresolved JIRAs
>> >>>> >>> that are tagged as 1.2, one of which is NIFI-3380, and I figured
>> if
>> >>>> >>> someone looked at the ticket it might look like no work had been
>> done
>> >>>> >>> and figure that it can just be moved to next release, so I just
>> wanted
>> >>>> >>> to mention that it is very close to being ready was still hoping
>> for
>> >>>> >>> it be in 1.2, unless there was strong opinion to move on without
>> it.
>> >>>> >>> Even if we moved on without it, I believe there is still a bit of
>> work
>> >>>> >>> to do in that we still need a release manager and we need to
>> decide
>> >>>> >>> what to do with the 39 JIRAs.
>> >>>> >>>
>> >>>> >>> As far as the new NAR plugin and how things will work...
>> >>>> >>>
>> >>>> >>> The changes to the NAR plugin add additional information to the
>> >>>> >>> MANIFEST file in the NAR. Technically existing NiFi would have no
>> >>>> >>> problem reading the new MANIFEST file because no entries are being
>> >>>> >>> removed, and the branch I have with the component versioning code
>> for
>> >>>> >>> NiFi could also run against old NARs that don't have the new
>> entries,
>> >>>> >>> you just see everything as being "unversioned" and can't actually
>> make
>> >>>> >>> use of the new capabilities. We'll always have to be able to run
>> older
>> >>>> >>> NARs because there are tons of custom NARs out there that have not
>> >>>> >>> been (and may never be) rebuilt with the newer version of the
>> plugin,
>> >>>> >>> which is fine, they only need to be rebuilt if someone wants to
>> run
>> >>>> >>> two versions of that NAR at the same time.
>> >>>> >>>
>> >>>> >>> Happy to elaborate more on any of the component versioning work if
>> >>>> >>> anyone is interested.
>> >>>> >>>
>> >>>> >>> Thanks,
>> >>>> >>>
>> >>>> >>> Bryan
>> >>>> >>>
>> >>>> >>>
>> >>>> >>> On Wed, Mar 8, 2017 at 2:43 PM, Russell Bateman <
>> russ@windofkeltia.com
>> >>>> >
>> >>>> >>> wrote:
>> >>>> >>> > +1 for component versioning in NiFi 1.2!
>> >>>> >>> >
>> >>>> >>> >
>> >>>> >>> > On 03/08/2017 12:40 PM, James Wing wrote:
>> >>>> >>> >>
>> >>>> >>> >> Bryan, I'm 100% in favor of you and Matt Gilman doing all the
>> hard
>> >>>> work.
>> >>>> >>> >> Oh, and uh... thanks! :)
>> >>>> >>> >>
>> >>>> >>> >> So the alternatives are:
>> >>>> >>> >> a.) Release 1.2.0 sooner (?), but without component versioning
>> >>>> >>> >> b.) Delay 1.2.0 (?) to incorporate component versioning
>> >>>> >>> >>
>> >>>> >>> >> Will the NAR plugin alone commit us to all of the component
>> >>>> versioning
>> >>>> >>> >> work
>> >>>> >>> >> in 1.2, or will the new NAR format be backward-compatible?  Or
>> is
>> >>>> the
>> >>>> >>> >> question more about the strategy for 1.2.0?
>> >>>> >>> >>
>> >>>> >>> >>
>> >>>> >>> >> Thanks,
>> >>>> >>> >>
>> >>>> >>> >> James
>> >>>> >>> >>
>> >>>> >>> >> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bb...@gmail.com>
>> >>>> wrote:
>> >>>> >>> >>
>> >>>> >>> >>> Just wanted to mention that one of the JIRAs tagged for 1.2.0
>> is
>> >>>> >>> >>> NIFI-3380 "support multiple versions of the same component"
>> [1] and
>> >>>> >>> >>> I've been working with Matt Gilman on this [2]. The
>> functionality
>> >>>> is
>> >>>> >>> >>> very close to being done and I think we should get this into
>> the
>> >>>> 1.2.0
>> >>>> >>> >>> release.
>> >>>> >>> >>>
>> >>>> >>> >>> In order to fully leverage the versioned components we will
>> need to
>> >>>> >>> >>> release an updated Maven NAR plugin, so we would do that
>> first and
>> >>>> >>> >>> then release 1.2.0 using the new plugin. If everyone is
>> on-board
>> >>>> with
>> >>>> >>> >>> this plan then I can advise when we are ready to release the
>> new
>> >>>> >>> >>> plugin which would be soon.
>> >>>> >>> >>>
>> >>>> >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-3380
>> >>>> >>> >>> [2] https://github.com/bbende/nifi/tree/NIFI-3380
>> >>>> >>> >>>
>> >>>> >>> >>> On Fri, Mar 3, 2017 at 9:56 AM, Joe Gresock <
>> jgresock@gmail.com>
>> >>>> >>> wrote:
>> >>>> >>> >>>>
>> >>>> >>> >>>> This is good discussion that should continue, but what about
>> the
>> >>>> >>> >>>> original
>> >>>> >>> >>>> intent of Joe's post?  "Is there any reason folks can think
>> of to
>> >>>> hold
>> >>>> >>> >>>
>> >>>> >>> >>> off
>> >>>> >>> >>>>
>> >>>> >>> >>>> on a 1.2.0 release?"
>> >>>> >>> >>>>
>> >>>> >>> >>>> On Fri, Mar 3, 2017 at 1:45 PM, Mark Payne <
>> markap14@hotmail.com>
>> >>>> >>> wrote:
>> >>>> >>> >>>>
>> >>>> >>> >>>>> Andy,
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Sorry, i haven't responded to this thread in over a week,
>> but I
>> >>>> think
>> >>>> >>> >>>
>> >>>> >>> >>> it's
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> important to keep going.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I just clicked "Cancel Patch" on one of my ticket that has a
>> >>>> patch
>> >>>> >>> >>>>> available to see which state it returned to.
>> >>>> >>> >>>>> It did in fact go back to Open. Which I agree is less than
>> ideal.
>> >>>> >>> >>>>> Though
>> >>>> >>> >>>>> we could certainly have a process
>> >>>> >>> >>>>> by which we change the status to "In Progress" after
>> canceling
>> >>>> the
>> >>>> >>> >>>
>> >>>> >>> >>> patch.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I guess where my viewpoint differs from yours is in the
>> meaning
>> >>>> of
>> >>>> >>> "In
>> >>>> >>> >>>>> Review." Let's say that you submit a
>> >>>> >>> >>>>> patch for a JIRA. I then review it and find that it needs
>> some
>> >>>> work -
>> >>>> >>> >>>>> let's say there's an issue with licensing
>> >>>> >>> >>>>> not being properly accounted for, for instance. At that
>> point, I
>> >>>> no
>> >>>> >>> >>>
>> >>>> >>> >>> longer
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> consider the patch that you provided
>> >>>> >>> >>>>> to be "In Review." I believe the patch should be canceled,
>> and
>> >>>> you
>> >>>> >>> will
>> >>>> >>> >>>>> need to submit a new patch. I guess
>> >>>> >>> >>>>> that I view a patch as being an immutable entity.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 24, 2017, at 7:26 PM, Andy LoPresto <
>> alopresto@apache.org
>> >>>> >>> >>>
>> >>>> >>> >>> <mailto:a
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> lopresto@apache.org>> wrote:
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Mark,
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Your understanding of “Patch Available” certainly makes
>> sense
>> >>>> and it
>> >>>> >>> >>>>> explains why you approach the process the way you do. I
>> have a
>> >>>> >>> slightly
>> >>>> >>> >>>>> different personal understanding of “Patch Available” — I
>> read
>> >>>> it to
>> >>>> >>> >>>
>> >>>> >>> >>> mean
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> “the person responsible for this Jira has contributed code
>> they
>> >>>> feel
>> >>>> >>> >>>
>> >>>> >>> >>> solves
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> the issue.” A review will (hopefully) determine if that
>> >>>> assertion is
>> >>>> >>> >>>>> correct and complete. I think we kind of agree on "my
>> viewpoint
>> >>>> is
>> >>>> >>> >>>
>> >>>> >>> >>> simply
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> that "Patch Available" means "Awaiting Review" or "In
>> Review.””
>> >>>> but I
>> >>>> >>> >>>
>> >>>> >>> >>> see
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> “In Review” as a potentially iterative process — it could
>> be on
>> >>>> the
>> >>>> >>> >>>
>> >>>> >>> >>> second
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> pass of the contributor responding to comments, but it’s
>> still
>> >>>> “In
>> >>>> >>> >>>
>> >>>> >>> >>> Review”
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> in my eyes. I don’t know that the granularity of Jira
>> supports
>> >>>> the
>> >>>> >>> >>>
>> >>>> >>> >>> specific
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> workflow states of “been reviewed once but not
>> complete/accepted
>> >>>> >>> yet”.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> What state does “Cancel Patch” result in? If it just
>> reverts to
>> >>>> >>> “Open”,
>> >>>> >>> >>>
>> >>>> >>> >>> I
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> don’t see the value because that obfuscates the difference
>> >>>> between a
>> >>>> >>> >>>
>> >>>> >>> >>> Jira
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> that hasn’t even been touched and one that has 90% of the
>> code
>> >>>> done.
>> >>>> >>> I
>> >>>> >>> >>>>> agree we should make the RM’s job easier, but I also think
>> it
>> >>>> doesn’t
>> >>>> >>> >>>
>> >>>> >>> >>> help
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> the visibility for reviewers to see a Jira marked as “open”
>> when
>> >>>> >>> there
>> >>>> >>> >>>
>> >>>> >>> >>> is
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> the potential for that patch to be ready for merge in a very
>> >>>> short
>> >>>> >>> >>>
>> >>>> >>> >>> amount
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> of time.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I think these conversations will ultimately help us narrow
>> in on
>> >>>> >>> shared
>> >>>> >>> >>>>> definitions that make sense to everyone though, so I’m glad
>> we’re
>> >>>> >>> >>>
>> >>>> >>> >>> talking
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> about it.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Andy LoPresto
>> >>>> >>> >>>>> alopresto@apache.org<ma...@apache.org>
>> >>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
>> com>
>> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
>> 2F7D
>> >>>> EF69
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <
>> markap14@hotmail.com
>> >>>> >>> <mailto:m
>> >>>> >>> >>>>> arkap14@hotmail.com>> wrote:
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Andy,
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> If the reviewer is looking for clarification, then it may
>> make
>> >>>> sense
>> >>>> >>> to
>> >>>> >>> >>>>> leave the JIRA in "Patch Available" state
>> >>>> >>> >>>>> as you suggest. If there are minor fixes needed, though,
>> then the
>> >>>> >>> patch
>> >>>> >>> >>>
>> >>>> >>> >>> is
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> not ready. In JIRA, the verbiage for
>> >>>> >>> >>>>> Cancel Patch says "The patch is not yet ready to be
>> committed."
>> >>>> So if
>> >>>> >>> >>>>> minor fixes are needed, then I believe
>> >>>> >>> >>>>> it is appropriate to Cancel Patch. Once those changes
>> (minor or
>> >>>> not)
>> >>>> >>> >>>>> are
>> >>>> >>> >>>>> made and the PR updated, then the
>> >>>> >>> >>>>> PR needs review again and the status should be changed back
>> to
>> >>>> "Patch
>> >>>> >>> >>>>> Available" again.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I guess my viewpoint is simply that "Patch Available" means
>> >>>> "Awaiting
>> >>>> >>> >>>>> Review" or "In Review." If it is awaiting
>> >>>> >>> >>>>> changes of some kind and won't be merged as-is, then we
>> should
>> >>>> Cancel
>> >>>> >>> >>>>> Patch.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Do you or others have differing views on the meaning of
>> "Patch
>> >>>> >>> >>>
>> >>>> >>> >>> Available"?
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Thanks
>> >>>> >>> >>>>> -Mark
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 24, 2017, at 3:27 PM, Andy LoPresto <
>> alopresto@apache.org
>> >>>> >>> >>>
>> >>>> >>> >>> <mailto:a
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> lopresto@apache.org><ma...@apache.org>> wrote:
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Mark,
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I like your point about updating the Jira with the Fix
>> Version
>> >>>> at the
>> >>>> >>> >>>
>> >>>> >>> >>> time
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> the PR review begins (or when the PR is submitted, if the
>> >>>> contributor
>> >>>> >>> >>>>> is
>> >>>> >>> >>>>> aware of this process). I think it’s better than waiting
>> for the
>> >>>> >>> merge,
>> >>>> >>> >>>
>> >>>> >>> >>> as
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I proposed before.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I agree that the reviewer is responsible for keeping the
>> Jira
>> >>>> updated
>> >>>> >>> >>>>> in
>> >>>> >>> >>>>> line with their work. I don’t know if I am on the same page
>> as
>> >>>> you
>> >>>> >>> for
>> >>>> >>> >>>>> “Cancel Patch” if the PR needs changes; sometimes these are
>> minor
>> >>>> >>> fixes
>> >>>> >>> >>>
>> >>>> >>> >>> or
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> just looking for clarification from the contributor, and I
>> don’t
>> >>>> >>> think
>> >>>> >>> >>>
>> >>>> >>> >>> that
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> warrants canceling the availability of the patch. If they
>> are
>> >>>> major
>> >>>> >>> >>>>> architectural changes, then that makes more sense to me.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Andy LoPresto
>> >>>> >>> >>>>> alopresto@apache.org<ma...@apache.org><mailto:
>> alo
>> >>>> >>> >>>>> presto@apache.org>
>> >>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
>> com
>> >>>> >>> ><mailto:
>> >>>> >>> >>>>> alopresto.apache@gmail.com>
>> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
>> 2F7D
>> >>>> EF69
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <
>> markap14@hotmail.com
>> >>>> >>> <mailto:m
>> >>>> >>> >>>>> arkap14@hotmail.com><ma...@hotmail.com>> wrote:
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Personally, I am afraid that if we don't set a Fix Version
>> on
>> >>>> JIRA's,
>> >>>> >>> >>>
>> >>>> >>> >>> that
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> some PR's will be lost
>> >>>> >>> >>>>> or stalled. I rarely go to github and start looking through
>> the
>> >>>> PRs.
>> >>>> >>> >>>>> Instead, I go to JIRA and look
>> >>>> >>> >>>>> at what is assigned with a fixVersion of the next release.
>> Then
>> >>>> I'll
>> >>>> >>> go
>> >>>> >>> >>>>> and review JIRA's that are
>> >>>> >>> >>>>> in a state of "Patch Available." Even then I often come
>> across
>> >>>> many
>> >>>> >>> >>>>> PR's
>> >>>> >>> >>>>> that have already been
>> >>>> >>> >>>>> reviewed by one or more other committers and are awaiting
>> >>>> updates.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> So I propose that we address this slightly differently. I
>> believe
>> >>>> >>> that
>> >>>> >>> >>>
>> >>>> >>> >>> we
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> should assign a Fix Version to
>> >>>> >>> >>>>> a JIRA whenever a PR is submitted. Then, whenever a
>> committer
>> >>>> >>> reviews a
>> >>>> >>> >>>>> PR, he/she should be
>> >>>> >>> >>>>> responsible for updating the JIRA. If the PR is merged then
>> the
>> >>>> JIRA
>> >>>> >>> >>>>> should be resolved as Fixed.
>> >>>> >>> >>>>> But if the PR is not merged because some changes are
>> needed, the
>> >>>> >>> >>>
>> >>>> >>> >>> reviewer
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> should then go back to
>> >>>> >>> >>>>> the JIRA and click 'Cancel Patch'. We are typically very
>> good
>> >>>> about
>> >>>> >>> >>>>> resolving as fixed once a PR is
>> >>>> >>> >>>>> merged, but we don't typically cancel the patch otherwise.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> If we followed this workflow, then a Release Manager (or
>> anyone
>> >>>> else)
>> >>>> >>> >>>
>> >>>> >>> >>> can
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> easily see which tickets
>> >>>> >>> >>>>> need to be reviewed before a release happens and which ones
>> can
>> >>>> be
>> >>>> >>> >>>
>> >>>> >>> >>> pushed
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> out because they
>> >>>> >>> >>>>> are not ready (even if a PR has been posted). It also makes
>> it
>> >>>> much
>> >>>> >>> >>>
>> >>>> >>> >>> easier
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> for reviewers to quickly
>> >>>> >>> >>>>> know which tickets are awaiting review.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Thoughts?
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> -Mark
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 23, 2017, at 3:37 AM, Andy LoPresto <
>> >>>> >>> alopresto.apache@gmail.com<
>> >>>> >>> >>>>> mailto:alopresto.apache@gmail.com><mailto:
>> >>>> alopresto.apache@gmail.com
>> >>>> >>> >>
>> >>>> >>> >>>>> wrote:
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> As someone who has surely been guilty of optimistically
>> setting
>> >>>> fix
>> >>>> >>> >>>>> versions and then not meeting them, I second Joe's point
>> about it
>> >>>> >>> >>>
>> >>>> >>> >>> holding
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> up releases. Better to get the PR out, reviewed, and merged
>> >>>> *before*
>> >>>> >>> >>>>> setting the fix version in my opinion.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Andy LoPresto
>> >>>> >>> >>>>> alopresto@apache.org<ma...@apache.org><mailto:
>> alo
>> >>>> >>> >>>>> presto@apache.org>
>> >>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
>> com
>> >>>> >>> ><mailto:
>> >>>> >>> >>>>> alopresto.apache@gmail.com>
>> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
>> 2F7D
>> >>>> EF69
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.witt@gmail.com
>> <mailto:
>> >>>> joe
>> >>>> >>> >>>>> .witt@gmail.com>> wrote:
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Peter,
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> This is just my preference so discussion is certainly
>> open.  But
>> >>>> the
>> >>>> >>> >>>>> way I see it we should not set the fix version on JIRAs
>> unless
>> >>>> they
>> >>>> >>> >>>>> really should block a release without resolution or if due
>> to
>> >>>> some
>> >>>> >>> >>>>> roadmap/planning/discussion it is a new feature/improvement
>> that
>> >>>> is
>> >>>> >>> >>>>> tied to a release.  Otherwise, for the many things which
>> pop up
>> >>>> >>> >>>>> throughout a given release cycle they should be avoided.
>> That
>> >>>> is to
>> >>>> >>> >>>>> say the majority of the time we'd avoid fix versions until
>> the
>> >>>> act of
>> >>>> >>> >>>>> merging a contribution which also means it has been
>> reviewed.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>  From the release management point of view:
>> >>>> >>> >>>>> This approach helps greatly as until now it is has been
>> really
>> >>>> >>> >>>>> difficult and time consuming to pull together/close down a
>> >>>> release as
>> >>>> >>> >>>>> pretty much anyone can set these fix versions and make it
>> appear
>> >>>> as
>> >>>> >>> >>>>> though the release is not ready when in reality it is
>> perfectly
>> >>>> >>> >>>>> releasable as-is but might miss out on some contribs that
>> someone
>> >>>> >>> >>>>> would like to see in the release but has as of yet not
>> gotten
>> >>>> the PR
>> >>>> >>> >>>>> and/or review traction necessary.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>  From the contributor point of view:
>> >>>> >>> >>>>> If someone makes a contribution they obviously want that
>> code to
>> >>>> end
>> >>>> >>> >>>>> up in a release.  But being an RTC community we need and
>> want
>> >>>> peer
>> >>>> >>> >>>>> review before the code is submitted.  Some contributions are
>> >>>> frankly
>> >>>> >>> >>>>> hard to get peer review on or simply take time for someone
>> to
>> >>>> >>> >>>>> volunteer to do.  PRs which are difficult to test, lack
>> testing,
>> >>>> are
>> >>>> >>> >>>>> related to systems or environments which are not easily
>> >>>> replicated,
>> >>>> >>> >>>>> etc.. are inherently harder to get peer review for.  Also,
>> the
>> >>>> >>> >>>>> community has grown quite rapidly and sometimes the hygiene
>> of a
>> >>>> >>> given
>> >>>> >>> >>>>> PR isn't great.  So our 'patch available' and 'open PR'
>> count
>> >>>> ticks
>> >>>> >>> >>>>> up.  We need reviews/feedback as much as we need
>> contributions
>> >>>> so it
>> >>>> >>> >>>>> is important for folks that want those contributions in to
>> build
>> >>>> >>> >>>>> meritocracy as well in reviewing others contributions.  This
>> >>>> helps
>> >>>> >>> >>>>> build a network of contributors/reviewers and improves the
>> >>>> timeliness
>> >>>> >>> >>>>> of reviews.  Long story short here is that because at times
>> PRs
>> >>>> can
>> >>>> >>> >>>>> sit too long sometimes people put a fix version on the JIRA
>> so it
>> >>>> >>> acts
>> >>>> >>> >>>>> as a sort of 'gating function' on the release.  This I am
>> saying
>> >>>> is
>> >>>> >>> >>>>> the practice that should not occur (given the thoughts
>> above).
>> >>>> We
>> >>>> >>> >>>>> should instead take the issue of how to more effectively
>> >>>> >>> >>>>> triage/review/provide feedback/and manage expectations for
>> >>>> >>> >>>>> contributions so contributors don't feel like their stuff
>> will
>> >>>> just
>> >>>> >>> >>>>> sit forever.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Does that make sense and seem fair?
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Thanks
>> >>>> >>> >>>>> Joe
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) <
>> >>>> >>> >>>
>> >>>> >>> >>> pwicks@micron.com
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> <ma...@micron.com>> wrote:
>> >>>> >>> >>>>> Just for clarification, "We really need to avoid the
>> practice of
>> >>>> >>> >>>>> setting
>> >>>> >>> >>>>> fix versions without traction", would mean don't set a
>> version
>> >>>> number
>> >>>> >>> >>>
>> >>>> >>> >>> until
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> after we've submitted a PR? Until after the PR has been
>> closed?
>> >>>> >>> Other?
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Thanks,
>> >>>> >>> >>>>> Peter
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> -----Original Message-----
>> >>>> >>> >>>>> From: Joe Witt [mailto:joe.witt@gmail.com]
>> >>>> >>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>> >>>> >>> >>>>> To: dev@nifi.apache.org<ma...@nifi.apache.org>
>> >>>> >>> >>>>> Subject: Closing in on a NiFi 1.2.0 release?
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> team,
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On the users lists we had an ask of when we are planning to
>> cut a
>> >>>> >>> >>>>> 1.2.0 release.  And someone else asked me recently off-list.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> There are 45 open JIRAs tagged to it as of now.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> https://issues.apache.org/jira/issues/?jql=project%20%
>> >>>> >>> >>>>>
>> >>>> 3D%20NIFI%20AND%20fixVersion%20%3D%201.2.0%20AND%20resolution%20%3D%
>> >>>> >>> >>>>> 20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> I'd be favorable to going through and seeing if we can
>> start the
>> >>>> >>> >>>>> motions
>> >>>> >>> >>>>> for a 1.2.0 release and which are ones we can wait for and
>> which
>> >>>> we
>> >>>> >>> >>>
>> >>>> >>> >>> should
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> have in 1.2.0 for sure.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Is there any reason folks can think of to hold off on a
>> 1.2.0
>> >>>> >>> release?
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> A non trivial number of the JIRAs are for things which have
>> or
>> >>>> do not
>> >>>> >>> >>>
>> >>>> >>> >>> have
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> PRs but have no review traction.  We really need to avoid
>> the
>> >>>> >>> practice
>> >>>> >>> >>>
>> >>>> >>> >>> of
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> setting fix versions without traction on this as otherwise
>> it
>> >>>> holds
>> >>>> >>> up
>> >>>> >>> >>>
>> >>>> >>> >>> the
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> releases.
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> Thanks
>> >>>> >>> >>>>> Joe
>> >>>> >>> >>>>>
>> >>>> >>> >>>>>
>> >>>> >>> >>>>
>> >>>> >>> >>>> --
>> >>>> >>> >>>> I know what it is to be in need, and I know what it is to
>> have
>> >>>> plenty.
>> >>>> >>> >>>> I
>> >>>> >>> >>>> have learned the secret of being content in any and every
>> >>>> situation,
>> >>>> >>> >>>> whether well fed or hungry, whether living in plenty or in
>> want.
>> >>>> I
>> >>>> >>> can
>> >>>> >>> >>>
>> >>>> >>> >>> do
>> >>>> >>> >>>>
>> >>>> >>> >>>> all this through him who gives me strength.    *-Philippians
>> >>>> 4:12-13*
>> >>>> >>> >
>> >>>> >>> >
>> >>>> >>>
>> >>>>
>> >>> --
>> >>> Sent from Gmail Mobile
>>

Re: Closing in on a NiFi 1.2.0 release?

[Tony Kurc <tr...@gmail.com>]

Joe et. al,
I think this one is close too (mainly dotting i's and crossing t's on
license and notice)

https://issues.apache.org/jira/browse/NIFI-3586

On Tue, Apr 4, 2017 at 2:23 PM, Joe Witt <jo...@gmail.com> wrote:

> Team,
>
> Another update on efforts to close-in on the NiFi 1.2.0 release.
> We're below 20 JIRAs now and there has been good momentum.  A couple
> items still need work but look really important and then there is
> review traction/feedback cycles.  Will just keep monitoring it and
> actively defending to close the loop on 1.2.0 until we're there.
>
> Thanks
> Joe
>
> On Tue, Mar 28, 2017 at 9:45 AM, Joe Witt <jo...@gmail.com> wrote:
> > Team,
> >
> > Status of JIRA cleanup toward an Apache NiFi 1.2.0 release candidate
> > which Mr Bende has so wonderfully volunteered to RM:
> >
> > There are 20 open JIRAs as of now.
> >
> > 12 of 20 have PRs that appear ready/close to ready.
> >
> > One pattern I noticed quite a bit on the 1.2.0 release is heavy usage
> > of 'squatter JIRAs' whereby someone makes a JIRA and with or without
> > any review traction and for non blocking issues sets the fix version.
> > This practice should be avoided.  The fix version should be reserved
> > for once there is a blocker item or there is something with a patch
> > contributed and review progress closing in on a merge.
> >
> > One of them means we need to punt the Twitter processor most likely.
> > Don't believe there were new releases to resolve that licensing issue
> > by the third party dependency.  I'll take that on.
> >   https://issues.apache.org/jira/browse/NIFI-3089
> >
> > Two of them are build failure issues which means windows and linux
> > builds break (highly repeatable):
> >   https://issues.apache.org/jira/browse/NIFI-3441
> >   https://issues.apache.org/jira/browse/NIFI-3440
> >
> > A couple need to either be moved out or addressed for implementation
> > or review but it isn't clear to me their status:
> >   https://issues.apache.org/jira/browse/NIFI-3155
> >   https://issues.apache.org/jira/browse/NIFI-1280
> >   https://issues.apache.org/jira/browse/NIFI-2656
> >   https://issues.apache.org/jira/browse/NIFI-2886
> >
> > Some are really important and being worked still:
> >   https://issues.apache.org/jira/browse/NIFI-3520
> >
> > Thanks
> > Joe
> >
> > On Wed, Mar 22, 2017 at 9:12 PM, Joe Witt <jo...@gmail.com> wrote:
> >> Sweet!  I'll take that deal all day.  Thanks Bryan!
> >>
> >> On Wed, Mar 22, 2017 at 8:26 PM, Bryan Bende <bb...@gmail.com> wrote:
> >>> Joe,
> >>>
> >>> As of today I believe the PR for NIFI-3380 (component versioning)
> should
> >>> address all of the code review feedback and is in a good place.
> >>>
> >>> Would like to run through a few more tests tomorrow, and baring any
> >>> additional feedback from reviewers, we could possibly merge that
> tomorrow.
> >>> That PR will also bump master to use the newly released NAR plugin.
> >>>
> >>> Since I got a warm-up with NAR plugin, I don't mind taking on release
> >>> manager duties for 1.2, although I would still like help on the JIRA
> >>> whipping. I imagine there's still a bit of work to narrow down the
> >>> remaining tickets.
> >>>
> >>> -Bryan
> >>>
> >>> On Wed, Mar 22, 2017 at 7:35 PM Joe Witt <jo...@gmail.com> wrote:
> >>>
> >>>> Bryan
> >>>>
> >>>> How are things looking for what you updated on?  The nar plugin of
> >>>> course is out.
> >>>>
> >>>> We got another question on the user list for 1.2 so I just want to
> >>>> make sure we're closing in.  I'll start doing the JIRA whipping.
> >>>>
> >>>> Thanks
> >>>> JOe
> >>>>
> >>>> On Mon, Mar 13, 2017 at 3:22 PM, Bryan Bende <bb...@gmail.com>
> wrote:
> >>>> > Just a quick update on this discussion...
> >>>> >
> >>>> > On Friday we were able to post an initial PR for the component
> >>>> > versioning work [1].
> >>>> >
> >>>> > I believe we are ready to move forward with a release of the NAR
> Maven
> >>>> > plugin, there are three tickets to be included in the release [2].
> >>>> >
> >>>> > If there are no objections, I can take on the release manager duties
> >>>> > for the NAR plugin, and can begin to kick off the process tomorrow.
> >>>> >
> >>>> > -Bryan
> >>>> >
> >>>> > [1] https://github.com/apache/nifi/pull/1585
> >>>> > [2]
> >>>> https://issues.apache.org/jira/browse/NIFI-3589?jql=
> fixVersion%20%3D%20nifi-nar-maven-plugin-1.2.0%20AND%
> 20project%20%3D%20NIFI
> >>>> >
> >>>> > On Wed, Mar 8, 2017 at 6:19 PM, James Wing <jv...@gmail.com>
> wrote:
> >>>> >> +1 for component versioning in 1.2.0, it will be a solid capstone
> >>>> feature.
> >>>> >> And I agree it's probably not holding up the release.
> >>>> >>
> >>>> >> Thanks,
> >>>> >>
> >>>> >> James
> >>>> >>
> >>>> >> On Wed, Mar 8, 2017 at 1:21 PM, Bryan Bende <bb...@gmail.com>
> wrote:
> >>>> >>
> >>>> >>> James,
> >>>> >>>
> >>>> >>> No problem :)
> >>>> >>>
> >>>> >>> I was mostly just suggesting an overall strategy...
> >>>> >>>
> >>>> >>> Usually when we start closing in on a release we go through the
> JIRAs
> >>>> >>> tagged for that release and try to figure out which ones can be
> moved
> >>>> >>> to a future release, and which ones the community is actually
> working
> >>>> >>> on and close to being ready. Currently we have 39 unresolved JIRAs
> >>>> >>> that are tagged as 1.2, one of which is NIFI-3380, and I figured
> if
> >>>> >>> someone looked at the ticket it might look like no work had been
> done
> >>>> >>> and figure that it can just be moved to next release, so I just
> wanted
> >>>> >>> to mention that it is very close to being ready was still hoping
> for
> >>>> >>> it be in 1.2, unless there was strong opinion to move on without
> it.
> >>>> >>> Even if we moved on without it, I believe there is still a bit of
> work
> >>>> >>> to do in that we still need a release manager and we need to
> decide
> >>>> >>> what to do with the 39 JIRAs.
> >>>> >>>
> >>>> >>> As far as the new NAR plugin and how things will work...
> >>>> >>>
> >>>> >>> The changes to the NAR plugin add additional information to the
> >>>> >>> MANIFEST file in the NAR. Technically existing NiFi would have no
> >>>> >>> problem reading the new MANIFEST file because no entries are being
> >>>> >>> removed, and the branch I have with the component versioning code
> for
> >>>> >>> NiFi could also run against old NARs that don't have the new
> entries,
> >>>> >>> you just see everything as being "unversioned" and can't actually
> make
> >>>> >>> use of the new capabilities. We'll always have to be able to run
> older
> >>>> >>> NARs because there are tons of custom NARs out there that have not
> >>>> >>> been (and may never be) rebuilt with the newer version of the
> plugin,
> >>>> >>> which is fine, they only need to be rebuilt if someone wants to
> run
> >>>> >>> two versions of that NAR at the same time.
> >>>> >>>
> >>>> >>> Happy to elaborate more on any of the component versioning work if
> >>>> >>> anyone is interested.
> >>>> >>>
> >>>> >>> Thanks,
> >>>> >>>
> >>>> >>> Bryan
> >>>> >>>
> >>>> >>>
> >>>> >>> On Wed, Mar 8, 2017 at 2:43 PM, Russell Bateman <
> russ@windofkeltia.com
> >>>> >
> >>>> >>> wrote:
> >>>> >>> > +1 for component versioning in NiFi 1.2!
> >>>> >>> >
> >>>> >>> >
> >>>> >>> > On 03/08/2017 12:40 PM, James Wing wrote:
> >>>> >>> >>
> >>>> >>> >> Bryan, I'm 100% in favor of you and Matt Gilman doing all the
> hard
> >>>> work.
> >>>> >>> >> Oh, and uh... thanks! :)
> >>>> >>> >>
> >>>> >>> >> So the alternatives are:
> >>>> >>> >> a.) Release 1.2.0 sooner (?), but without component versioning
> >>>> >>> >> b.) Delay 1.2.0 (?) to incorporate component versioning
> >>>> >>> >>
> >>>> >>> >> Will the NAR plugin alone commit us to all of the component
> >>>> versioning
> >>>> >>> >> work
> >>>> >>> >> in 1.2, or will the new NAR format be backward-compatible?  Or
> is
> >>>> the
> >>>> >>> >> question more about the strategy for 1.2.0?
> >>>> >>> >>
> >>>> >>> >>
> >>>> >>> >> Thanks,
> >>>> >>> >>
> >>>> >>> >> James
> >>>> >>> >>
> >>>> >>> >> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bb...@gmail.com>
> >>>> wrote:
> >>>> >>> >>
> >>>> >>> >>> Just wanted to mention that one of the JIRAs tagged for 1.2.0
> is
> >>>> >>> >>> NIFI-3380 "support multiple versions of the same component"
> [1] and
> >>>> >>> >>> I've been working with Matt Gilman on this [2]. The
> functionality
> >>>> is
> >>>> >>> >>> very close to being done and I think we should get this into
> the
> >>>> 1.2.0
> >>>> >>> >>> release.
> >>>> >>> >>>
> >>>> >>> >>> In order to fully leverage the versioned components we will
> need to
> >>>> >>> >>> release an updated Maven NAR plugin, so we would do that
> first and
> >>>> >>> >>> then release 1.2.0 using the new plugin. If everyone is
> on-board
> >>>> with
> >>>> >>> >>> this plan then I can advise when we are ready to release the
> new
> >>>> >>> >>> plugin which would be soon.
> >>>> >>> >>>
> >>>> >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-3380
> >>>> >>> >>> [2] https://github.com/bbende/nifi/tree/NIFI-3380
> >>>> >>> >>>
> >>>> >>> >>> On Fri, Mar 3, 2017 at 9:56 AM, Joe Gresock <
> jgresock@gmail.com>
> >>>> >>> wrote:
> >>>> >>> >>>>
> >>>> >>> >>>> This is good discussion that should continue, but what about
> the
> >>>> >>> >>>> original
> >>>> >>> >>>> intent of Joe's post?  "Is there any reason folks can think
> of to
> >>>> hold
> >>>> >>> >>>
> >>>> >>> >>> off
> >>>> >>> >>>>
> >>>> >>> >>>> on a 1.2.0 release?"
> >>>> >>> >>>>
> >>>> >>> >>>> On Fri, Mar 3, 2017 at 1:45 PM, Mark Payne <
> markap14@hotmail.com>
> >>>> >>> wrote:
> >>>> >>> >>>>
> >>>> >>> >>>>> Andy,
> >>>> >>> >>>>>
> >>>> >>> >>>>> Sorry, i haven't responded to this thread in over a week,
> but I
> >>>> think
> >>>> >>> >>>
> >>>> >>> >>> it's
> >>>> >>> >>>>>
> >>>> >>> >>>>> important to keep going.
> >>>> >>> >>>>>
> >>>> >>> >>>>> I just clicked "Cancel Patch" on one of my ticket that has a
> >>>> patch
> >>>> >>> >>>>> available to see which state it returned to.
> >>>> >>> >>>>> It did in fact go back to Open. Which I agree is less than
> ideal.
> >>>> >>> >>>>> Though
> >>>> >>> >>>>> we could certainly have a process
> >>>> >>> >>>>> by which we change the status to "In Progress" after
> canceling
> >>>> the
> >>>> >>> >>>
> >>>> >>> >>> patch.
> >>>> >>> >>>>>
> >>>> >>> >>>>> I guess where my viewpoint differs from yours is in the
> meaning
> >>>> of
> >>>> >>> "In
> >>>> >>> >>>>> Review." Let's say that you submit a
> >>>> >>> >>>>> patch for a JIRA. I then review it and find that it needs
> some
> >>>> work -
> >>>> >>> >>>>> let's say there's an issue with licensing
> >>>> >>> >>>>> not being properly accounted for, for instance. At that
> point, I
> >>>> no
> >>>> >>> >>>
> >>>> >>> >>> longer
> >>>> >>> >>>>>
> >>>> >>> >>>>> consider the patch that you provided
> >>>> >>> >>>>> to be "In Review." I believe the patch should be canceled,
> and
> >>>> you
> >>>> >>> will
> >>>> >>> >>>>> need to submit a new patch. I guess
> >>>> >>> >>>>> that I view a patch as being an immutable entity.
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 24, 2017, at 7:26 PM, Andy LoPresto <
> alopresto@apache.org
> >>>> >>> >>>
> >>>> >>> >>> <mailto:a
> >>>> >>> >>>>>
> >>>> >>> >>>>> lopresto@apache.org>> wrote:
> >>>> >>> >>>>>
> >>>> >>> >>>>> Mark,
> >>>> >>> >>>>>
> >>>> >>> >>>>> Your understanding of “Patch Available” certainly makes
> sense
> >>>> and it
> >>>> >>> >>>>> explains why you approach the process the way you do. I
> have a
> >>>> >>> slightly
> >>>> >>> >>>>> different personal understanding of “Patch Available” — I
> read
> >>>> it to
> >>>> >>> >>>
> >>>> >>> >>> mean
> >>>> >>> >>>>>
> >>>> >>> >>>>> “the person responsible for this Jira has contributed code
> they
> >>>> feel
> >>>> >>> >>>
> >>>> >>> >>> solves
> >>>> >>> >>>>>
> >>>> >>> >>>>> the issue.” A review will (hopefully) determine if that
> >>>> assertion is
> >>>> >>> >>>>> correct and complete. I think we kind of agree on "my
> viewpoint
> >>>> is
> >>>> >>> >>>
> >>>> >>> >>> simply
> >>>> >>> >>>>>
> >>>> >>> >>>>> that "Patch Available" means "Awaiting Review" or "In
> Review.””
> >>>> but I
> >>>> >>> >>>
> >>>> >>> >>> see
> >>>> >>> >>>>>
> >>>> >>> >>>>> “In Review” as a potentially iterative process — it could
> be on
> >>>> the
> >>>> >>> >>>
> >>>> >>> >>> second
> >>>> >>> >>>>>
> >>>> >>> >>>>> pass of the contributor responding to comments, but it’s
> still
> >>>> “In
> >>>> >>> >>>
> >>>> >>> >>> Review”
> >>>> >>> >>>>>
> >>>> >>> >>>>> in my eyes. I don’t know that the granularity of Jira
> supports
> >>>> the
> >>>> >>> >>>
> >>>> >>> >>> specific
> >>>> >>> >>>>>
> >>>> >>> >>>>> workflow states of “been reviewed once but not
> complete/accepted
> >>>> >>> yet”.
> >>>> >>> >>>>>
> >>>> >>> >>>>> What state does “Cancel Patch” result in? If it just
> reverts to
> >>>> >>> “Open”,
> >>>> >>> >>>
> >>>> >>> >>> I
> >>>> >>> >>>>>
> >>>> >>> >>>>> don’t see the value because that obfuscates the difference
> >>>> between a
> >>>> >>> >>>
> >>>> >>> >>> Jira
> >>>> >>> >>>>>
> >>>> >>> >>>>> that hasn’t even been touched and one that has 90% of the
> code
> >>>> done.
> >>>> >>> I
> >>>> >>> >>>>> agree we should make the RM’s job easier, but I also think
> it
> >>>> doesn’t
> >>>> >>> >>>
> >>>> >>> >>> help
> >>>> >>> >>>>>
> >>>> >>> >>>>> the visibility for reviewers to see a Jira marked as “open”
> when
> >>>> >>> there
> >>>> >>> >>>
> >>>> >>> >>> is
> >>>> >>> >>>>>
> >>>> >>> >>>>> the potential for that patch to be ready for merge in a very
> >>>> short
> >>>> >>> >>>
> >>>> >>> >>> amount
> >>>> >>> >>>>>
> >>>> >>> >>>>> of time.
> >>>> >>> >>>>>
> >>>> >>> >>>>> I think these conversations will ultimately help us narrow
> in on
> >>>> >>> shared
> >>>> >>> >>>>> definitions that make sense to everyone though, so I’m glad
> we’re
> >>>> >>> >>>
> >>>> >>> >>> talking
> >>>> >>> >>>>>
> >>>> >>> >>>>> about it.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Andy LoPresto
> >>>> >>> >>>>> alopresto@apache.org<ma...@apache.org>
> >>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
> com>
> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
> 2F7D
> >>>> EF69
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <
> markap14@hotmail.com
> >>>> >>> <mailto:m
> >>>> >>> >>>>> arkap14@hotmail.com>> wrote:
> >>>> >>> >>>>>
> >>>> >>> >>>>> Andy,
> >>>> >>> >>>>>
> >>>> >>> >>>>> If the reviewer is looking for clarification, then it may
> make
> >>>> sense
> >>>> >>> to
> >>>> >>> >>>>> leave the JIRA in "Patch Available" state
> >>>> >>> >>>>> as you suggest. If there are minor fixes needed, though,
> then the
> >>>> >>> patch
> >>>> >>> >>>
> >>>> >>> >>> is
> >>>> >>> >>>>>
> >>>> >>> >>>>> not ready. In JIRA, the verbiage for
> >>>> >>> >>>>> Cancel Patch says "The patch is not yet ready to be
> committed."
> >>>> So if
> >>>> >>> >>>>> minor fixes are needed, then I believe
> >>>> >>> >>>>> it is appropriate to Cancel Patch. Once those changes
> (minor or
> >>>> not)
> >>>> >>> >>>>> are
> >>>> >>> >>>>> made and the PR updated, then the
> >>>> >>> >>>>> PR needs review again and the status should be changed back
> to
> >>>> "Patch
> >>>> >>> >>>>> Available" again.
> >>>> >>> >>>>>
> >>>> >>> >>>>> I guess my viewpoint is simply that "Patch Available" means
> >>>> "Awaiting
> >>>> >>> >>>>> Review" or "In Review." If it is awaiting
> >>>> >>> >>>>> changes of some kind and won't be merged as-is, then we
> should
> >>>> Cancel
> >>>> >>> >>>>> Patch.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Do you or others have differing views on the meaning of
> "Patch
> >>>> >>> >>>
> >>>> >>> >>> Available"?
> >>>> >>> >>>>>
> >>>> >>> >>>>> Thanks
> >>>> >>> >>>>> -Mark
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 24, 2017, at 3:27 PM, Andy LoPresto <
> alopresto@apache.org
> >>>> >>> >>>
> >>>> >>> >>> <mailto:a
> >>>> >>> >>>>>
> >>>> >>> >>>>> lopresto@apache.org><ma...@apache.org>> wrote:
> >>>> >>> >>>>>
> >>>> >>> >>>>> Mark,
> >>>> >>> >>>>>
> >>>> >>> >>>>> I like your point about updating the Jira with the Fix
> Version
> >>>> at the
> >>>> >>> >>>
> >>>> >>> >>> time
> >>>> >>> >>>>>
> >>>> >>> >>>>> the PR review begins (or when the PR is submitted, if the
> >>>> contributor
> >>>> >>> >>>>> is
> >>>> >>> >>>>> aware of this process). I think it’s better than waiting
> for the
> >>>> >>> merge,
> >>>> >>> >>>
> >>>> >>> >>> as
> >>>> >>> >>>>>
> >>>> >>> >>>>> I proposed before.
> >>>> >>> >>>>>
> >>>> >>> >>>>> I agree that the reviewer is responsible for keeping the
> Jira
> >>>> updated
> >>>> >>> >>>>> in
> >>>> >>> >>>>> line with their work. I don’t know if I am on the same page
> as
> >>>> you
> >>>> >>> for
> >>>> >>> >>>>> “Cancel Patch” if the PR needs changes; sometimes these are
> minor
> >>>> >>> fixes
> >>>> >>> >>>
> >>>> >>> >>> or
> >>>> >>> >>>>>
> >>>> >>> >>>>> just looking for clarification from the contributor, and I
> don’t
> >>>> >>> think
> >>>> >>> >>>
> >>>> >>> >>> that
> >>>> >>> >>>>>
> >>>> >>> >>>>> warrants canceling the availability of the patch. If they
> are
> >>>> major
> >>>> >>> >>>>> architectural changes, then that makes more sense to me.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Andy LoPresto
> >>>> >>> >>>>> alopresto@apache.org<ma...@apache.org><mailto:
> alo
> >>>> >>> >>>>> presto@apache.org>
> >>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
> com
> >>>> >>> ><mailto:
> >>>> >>> >>>>> alopresto.apache@gmail.com>
> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
> 2F7D
> >>>> EF69
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <
> markap14@hotmail.com
> >>>> >>> <mailto:m
> >>>> >>> >>>>> arkap14@hotmail.com><ma...@hotmail.com>> wrote:
> >>>> >>> >>>>>
> >>>> >>> >>>>> Personally, I am afraid that if we don't set a Fix Version
> on
> >>>> JIRA's,
> >>>> >>> >>>
> >>>> >>> >>> that
> >>>> >>> >>>>>
> >>>> >>> >>>>> some PR's will be lost
> >>>> >>> >>>>> or stalled. I rarely go to github and start looking through
> the
> >>>> PRs.
> >>>> >>> >>>>> Instead, I go to JIRA and look
> >>>> >>> >>>>> at what is assigned with a fixVersion of the next release.
> Then
> >>>> I'll
> >>>> >>> go
> >>>> >>> >>>>> and review JIRA's that are
> >>>> >>> >>>>> in a state of "Patch Available." Even then I often come
> across
> >>>> many
> >>>> >>> >>>>> PR's
> >>>> >>> >>>>> that have already been
> >>>> >>> >>>>> reviewed by one or more other committers and are awaiting
> >>>> updates.
> >>>> >>> >>>>>
> >>>> >>> >>>>> So I propose that we address this slightly differently. I
> believe
> >>>> >>> that
> >>>> >>> >>>
> >>>> >>> >>> we
> >>>> >>> >>>>>
> >>>> >>> >>>>> should assign a Fix Version to
> >>>> >>> >>>>> a JIRA whenever a PR is submitted. Then, whenever a
> committer
> >>>> >>> reviews a
> >>>> >>> >>>>> PR, he/she should be
> >>>> >>> >>>>> responsible for updating the JIRA. If the PR is merged then
> the
> >>>> JIRA
> >>>> >>> >>>>> should be resolved as Fixed.
> >>>> >>> >>>>> But if the PR is not merged because some changes are
> needed, the
> >>>> >>> >>>
> >>>> >>> >>> reviewer
> >>>> >>> >>>>>
> >>>> >>> >>>>> should then go back to
> >>>> >>> >>>>> the JIRA and click 'Cancel Patch'. We are typically very
> good
> >>>> about
> >>>> >>> >>>>> resolving as fixed once a PR is
> >>>> >>> >>>>> merged, but we don't typically cancel the patch otherwise.
> >>>> >>> >>>>>
> >>>> >>> >>>>> If we followed this workflow, then a Release Manager (or
> anyone
> >>>> else)
> >>>> >>> >>>
> >>>> >>> >>> can
> >>>> >>> >>>>>
> >>>> >>> >>>>> easily see which tickets
> >>>> >>> >>>>> need to be reviewed before a release happens and which ones
> can
> >>>> be
> >>>> >>> >>>
> >>>> >>> >>> pushed
> >>>> >>> >>>>>
> >>>> >>> >>>>> out because they
> >>>> >>> >>>>> are not ready (even if a PR has been posted). It also makes
> it
> >>>> much
> >>>> >>> >>>
> >>>> >>> >>> easier
> >>>> >>> >>>>>
> >>>> >>> >>>>> for reviewers to quickly
> >>>> >>> >>>>> know which tickets are awaiting review.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Thoughts?
> >>>> >>> >>>>>
> >>>> >>> >>>>> -Mark
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 23, 2017, at 3:37 AM, Andy LoPresto <
> >>>> >>> alopresto.apache@gmail.com<
> >>>> >>> >>>>> mailto:alopresto.apache@gmail.com><mailto:
> >>>> alopresto.apache@gmail.com
> >>>> >>> >>
> >>>> >>> >>>>> wrote:
> >>>> >>> >>>>>
> >>>> >>> >>>>> As someone who has surely been guilty of optimistically
> setting
> >>>> fix
> >>>> >>> >>>>> versions and then not meeting them, I second Joe's point
> about it
> >>>> >>> >>>
> >>>> >>> >>> holding
> >>>> >>> >>>>>
> >>>> >>> >>>>> up releases. Better to get the PR out, reviewed, and merged
> >>>> *before*
> >>>> >>> >>>>> setting the fix version in my opinion.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Andy LoPresto
> >>>> >>> >>>>> alopresto@apache.org<ma...@apache.org><mailto:
> alo
> >>>> >>> >>>>> presto@apache.org>
> >>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.
> com
> >>>> >>> ><mailto:
> >>>> >>> >>>>> alopresto.apache@gmail.com>
> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
> 2F7D
> >>>> EF69
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.witt@gmail.com
> <mailto:
> >>>> joe
> >>>> >>> >>>>> .witt@gmail.com>> wrote:
> >>>> >>> >>>>>
> >>>> >>> >>>>> Peter,
> >>>> >>> >>>>>
> >>>> >>> >>>>> This is just my preference so discussion is certainly
> open.  But
> >>>> the
> >>>> >>> >>>>> way I see it we should not set the fix version on JIRAs
> unless
> >>>> they
> >>>> >>> >>>>> really should block a release without resolution or if due
> to
> >>>> some
> >>>> >>> >>>>> roadmap/planning/discussion it is a new feature/improvement
> that
> >>>> is
> >>>> >>> >>>>> tied to a release.  Otherwise, for the many things which
> pop up
> >>>> >>> >>>>> throughout a given release cycle they should be avoided.
> That
> >>>> is to
> >>>> >>> >>>>> say the majority of the time we'd avoid fix versions until
> the
> >>>> act of
> >>>> >>> >>>>> merging a contribution which also means it has been
> reviewed.
> >>>> >>> >>>>>
> >>>> >>> >>>>>  From the release management point of view:
> >>>> >>> >>>>> This approach helps greatly as until now it is has been
> really
> >>>> >>> >>>>> difficult and time consuming to pull together/close down a
> >>>> release as
> >>>> >>> >>>>> pretty much anyone can set these fix versions and make it
> appear
> >>>> as
> >>>> >>> >>>>> though the release is not ready when in reality it is
> perfectly
> >>>> >>> >>>>> releasable as-is but might miss out on some contribs that
> someone
> >>>> >>> >>>>> would like to see in the release but has as of yet not
> gotten
> >>>> the PR
> >>>> >>> >>>>> and/or review traction necessary.
> >>>> >>> >>>>>
> >>>> >>> >>>>>  From the contributor point of view:
> >>>> >>> >>>>> If someone makes a contribution they obviously want that
> code to
> >>>> end
> >>>> >>> >>>>> up in a release.  But being an RTC community we need and
> want
> >>>> peer
> >>>> >>> >>>>> review before the code is submitted.  Some contributions are
> >>>> frankly
> >>>> >>> >>>>> hard to get peer review on or simply take time for someone
> to
> >>>> >>> >>>>> volunteer to do.  PRs which are difficult to test, lack
> testing,
> >>>> are
> >>>> >>> >>>>> related to systems or environments which are not easily
> >>>> replicated,
> >>>> >>> >>>>> etc.. are inherently harder to get peer review for.  Also,
> the
> >>>> >>> >>>>> community has grown quite rapidly and sometimes the hygiene
> of a
> >>>> >>> given
> >>>> >>> >>>>> PR isn't great.  So our 'patch available' and 'open PR'
> count
> >>>> ticks
> >>>> >>> >>>>> up.  We need reviews/feedback as much as we need
> contributions
> >>>> so it
> >>>> >>> >>>>> is important for folks that want those contributions in to
> build
> >>>> >>> >>>>> meritocracy as well in reviewing others contributions.  This
> >>>> helps
> >>>> >>> >>>>> build a network of contributors/reviewers and improves the
> >>>> timeliness
> >>>> >>> >>>>> of reviews.  Long story short here is that because at times
> PRs
> >>>> can
> >>>> >>> >>>>> sit too long sometimes people put a fix version on the JIRA
> so it
> >>>> >>> acts
> >>>> >>> >>>>> as a sort of 'gating function' on the release.  This I am
> saying
> >>>> is
> >>>> >>> >>>>> the practice that should not occur (given the thoughts
> above).
> >>>> We
> >>>> >>> >>>>> should instead take the issue of how to more effectively
> >>>> >>> >>>>> triage/review/provide feedback/and manage expectations for
> >>>> >>> >>>>> contributions so contributors don't feel like their stuff
> will
> >>>> just
> >>>> >>> >>>>> sit forever.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Does that make sense and seem fair?
> >>>> >>> >>>>>
> >>>> >>> >>>>> Thanks
> >>>> >>> >>>>> Joe
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) <
> >>>> >>> >>>
> >>>> >>> >>> pwicks@micron.com
> >>>> >>> >>>>>
> >>>> >>> >>>>> <ma...@micron.com>> wrote:
> >>>> >>> >>>>> Just for clarification, "We really need to avoid the
> practice of
> >>>> >>> >>>>> setting
> >>>> >>> >>>>> fix versions without traction", would mean don't set a
> version
> >>>> number
> >>>> >>> >>>
> >>>> >>> >>> until
> >>>> >>> >>>>>
> >>>> >>> >>>>> after we've submitted a PR? Until after the PR has been
> closed?
> >>>> >>> Other?
> >>>> >>> >>>>>
> >>>> >>> >>>>> Thanks,
> >>>> >>> >>>>> Peter
> >>>> >>> >>>>>
> >>>> >>> >>>>> -----Original Message-----
> >>>> >>> >>>>> From: Joe Witt [mailto:joe.witt@gmail.com]
> >>>> >>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
> >>>> >>> >>>>> To: dev@nifi.apache.org<ma...@nifi.apache.org>
> >>>> >>> >>>>> Subject: Closing in on a NiFi 1.2.0 release?
> >>>> >>> >>>>>
> >>>> >>> >>>>> team,
> >>>> >>> >>>>>
> >>>> >>> >>>>> On the users lists we had an ask of when we are planning to
> cut a
> >>>> >>> >>>>> 1.2.0 release.  And someone else asked me recently off-list.
> >>>> >>> >>>>>
> >>>> >>> >>>>> There are 45 open JIRAs tagged to it as of now.
> >>>> >>> >>>>>
> >>>> >>> >>>>> https://issues.apache.org/jira/issues/?jql=project%20%
> >>>> >>> >>>>>
> >>>> 3D%20NIFI%20AND%20fixVersion%20%3D%201.2.0%20AND%20resolution%20%3D%
> >>>> >>> >>>>> 20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
> >>>> >>> >>>>>
> >>>> >>> >>>>> I'd be favorable to going through and seeing if we can
> start the
> >>>> >>> >>>>> motions
> >>>> >>> >>>>> for a 1.2.0 release and which are ones we can wait for and
> which
> >>>> we
> >>>> >>> >>>
> >>>> >>> >>> should
> >>>> >>> >>>>>
> >>>> >>> >>>>> have in 1.2.0 for sure.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Is there any reason folks can think of to hold off on a
> 1.2.0
> >>>> >>> release?
> >>>> >>> >>>>>
> >>>> >>> >>>>> A non trivial number of the JIRAs are for things which have
> or
> >>>> do not
> >>>> >>> >>>
> >>>> >>> >>> have
> >>>> >>> >>>>>
> >>>> >>> >>>>> PRs but have no review traction.  We really need to avoid
> the
> >>>> >>> practice
> >>>> >>> >>>
> >>>> >>> >>> of
> >>>> >>> >>>>>
> >>>> >>> >>>>> setting fix versions without traction on this as otherwise
> it
> >>>> holds
> >>>> >>> up
> >>>> >>> >>>
> >>>> >>> >>> the
> >>>> >>> >>>>>
> >>>> >>> >>>>> releases.
> >>>> >>> >>>>>
> >>>> >>> >>>>> Thanks
> >>>> >>> >>>>> Joe
> >>>> >>> >>>>>
> >>>> >>> >>>>>
> >>>> >>> >>>>
> >>>> >>> >>>> --
> >>>> >>> >>>> I know what it is to be in need, and I know what it is to
> have
> >>>> plenty.
> >>>> >>> >>>> I
> >>>> >>> >>>> have learned the secret of being content in any and every
> >>>> situation,
> >>>> >>> >>>> whether well fed or hungry, whether living in plenty or in
> want.
> >>>> I
> >>>> >>> can
> >>>> >>> >>>
> >>>> >>> >>> do
> >>>> >>> >>>>
> >>>> >>> >>>> all this through him who gives me strength.    *-Philippians
> >>>> 4:12-13*
> >>>> >>> >
> >>>> >>> >
> >>>> >>>
> >>>>
> >>> --
> >>> Sent from Gmail Mobile
>