Closing in on a NiFi 1.2.0 release?

[Joe Witt]

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

RE: Closing in on a NiFi 1.2.0 release?

[Peter Wicks (pwicks)]

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.w...@gmail.com] 
Sent: Wednesday, February 22, 2017 12:55 PM
To: dev@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

Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt]

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)  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.w...@gmail.com]
> Sent: Wednesday, February 22, 2017 12:55 PM
> To: dev@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

Re: Closing in on a NiFi 1.2.0 release?

[Andy LoPresto]

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
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Feb 22, 2017, at 19:39, Joe Witt  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)  
>> 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.w...@gmail.com]
>> Sent: Wednesday, February 22, 2017 12:55 PM
>> To: dev@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

Re: Closing in on a NiFi 1.2.0 release?

[Joe Gresock]

Slightly off topic, but your statement "we need reviews/feedback as much as
we need contributions" made me think that the project could somehow benefit
from the concept of Kanban Work In Progress limits.  Not sure how you'd
implement this with an open source project, but just a thought.

On Thu, Feb 23, 2017 at 8:37 AM, Andy LoPresto 
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
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> > On Feb 22, 2017, at 19:39, Joe Witt  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) <
> pwi...@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.w...@gmail.com]
> >> Sent: Wednesday, February 22, 2017 12:55 PM
> >> To: dev@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%
> 2

Re: Closing in on a NiFi 1.2.0 release?

[Mark Payne]

2:39 PM, Peter Wicks (pwicks)  
>>> 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.w...@gmail.com]
>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>> To: dev@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

Re: Closing in on a NiFi 1.2.0 release?

[Andy LoPresto]

o, 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)  
>>>> 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.w...@gmail.com]
>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>>> To: dev@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
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Closing in on a NiFi 1.2.0 release?

[Mark Payne]

r 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)  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.w...@gmail.com]
Sent: Wednesday, February 22, 2017 12:55 PM
To: dev@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

Re: Closing in on a NiFi 1.2.0 release?

[Andy LoPresto]

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 
> mailto:alopresto.apa...@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
> alopre...@apache.org<mailto:alopre...@apache.org>
> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> 
> On Feb 22, 2017, at 19:39, Joe Witt  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)  
> 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.w...@gmail.com]
> Sent: Wednesday, February 22, 2017 12:55 PM
> To: dev@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
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Closing in on a NiFi 1.2.0 release?

[Mark Payne]

'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 
mailto:alopresto.apa...@gmail.com><mailto:alopresto.apa...@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
alopre...@apache.org<mailto:alopre...@apache.org><mailto:alopre...@apache.org>
alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com><mailto:alopresto.apa...@gmail.com>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Feb 22, 2017, at 19:39, Joe Witt 
mailto:joe.w...@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) 
mailto:pwi...@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--

Re: Closing in on a NiFi 1.2.0 release?

[Joe Gresock]

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)  <mailto:pwi...@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.w...@gmail.com]
> Sent: Wednesday, February 22, 2017 12:55 PM
> To: dev@nifi.apache.org<mailto:dev@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*

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

s 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) > <mailto:pwi...@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.w...@gmail.com]
>> Sent: Wednesday, February 22, 2017 12:55 PM
>> To: dev@nifi.apache.org<mailto:dev@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*

Re: Closing in on a NiFi 1.2.0 release?

[James Wing]

t;
> >> -Mark
> >>
> >>
> >> On Feb 23, 2017, at 3:37 AM, Andy LoPresto  >> mailto:alopresto.apa...@gmail.com><mailto:alopresto.apa...@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
> >> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
> >> pre...@apache.org>
> >> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com> >> alopresto.apa...@gmail.com>
> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>
> >> On Feb 22, 2017, at 19:39, Joe Witt mailto:joe
> >> .w...@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) <
> pwi...@micron.com
> >> <mailto:pwi...@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.w...@gmail.com]
> >> Sent: Wednesday, February 22, 2017 12:55 PM
> >> To: dev@nifi.apache.org<mailto:dev@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*
>

Re: Closing in on a NiFi 1.2.0 release?

[Russell Bateman]

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) <

pwi...@micron.com

<mailto:pwi...@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.w...@gmail.com]
Sent: Wednesday, February 22, 2017 12:55 PM
To: dev@nifi.apache.org<mailto:dev@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*

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

 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
>>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>>>>> pre...@apache.org>
>>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com>>>>> alopresto.apa...@gmail.com>
>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>>
>>>>> On Feb 22, 2017, at 19:39, Joe Witt mailto:joe
>>>>> .w...@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) <
>>>
>>> pwi...@micron.com
>>>>>
>>>>> <mailto:pwi...@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.w...@gmail.com]
>>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>>>> To: dev@nifi.apache.org<mailto:dev@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*
>
>

Re: Closing in on a NiFi 1.2.0 release?

[James Wing]

t;>>>
> >>>>> 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.apa...@gmail.com<
> >>>>> mailto:alopresto.apa...@gmail.com><mailto:alopresto.apa...@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
> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
> >>>>> pre...@apache.org>
> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
> > >>>>> alopresto.apa...@gmail.com>
> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>>>>
> >>>>> On Feb 22, 2017, at 19:39, Joe Witt mailto:joe
> >>>>> .w...@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) <
> >>>
> >>> pwi...@micron.com
> >>>>>
> >>>>> <mailto:pwi...@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.w...@gmail.com]
> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
> >>>>> To: dev@nifi.apache.org<mailto:dev@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*
> >
> >
>

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

 warrants canceling the availability of the patch. If they are major
>> >>>>> architectural changes, then that makes more sense to me.
>> >>>>>
>> >>>>> Andy LoPresto
>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>> >>>>> pre...@apache.org>
>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>> >> >>>>> alopresto.apa...@gmail.com>
>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >>>>>
>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne > > >>>>> arka...@hotmail.com><mailto:marka...@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.apa...@gmail.com<
>> >>>>> mailto:alopresto.apa...@gmail.com><mailto:alopresto.apa...@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
>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>> >>>>> pre...@apache.org>
>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>> >> >>>>> alopresto.apa...@gmail.com>
>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >>>>>
>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt mailto:joe
>> >>>>> .w...@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) <
>> >>>
>> >>> pwi...@micron.com
>> >>>>>
>> >>>>> <mailto:pwi...@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.w...@gmail.com]
>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>> >>>>> To: dev@nifi.apache.org<mailto:dev@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*
>> >
>> >
>>

Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt]

gt; >>>>>
>>> >>>>> lopre...@apache.org><mailto:alopre...@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
>>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>>> >>>>> pre...@apache.org>
>>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>>> >>> >>>>> alopresto.apa...@gmail.com>
>>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>> >>>>>
>>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne >> >> >>>>> arka...@hotmail.com><mailto:marka...@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.apa...@gmail.com<
>>> >>>>> mailto:alopresto.apa...@gmail.com><mailto:alopresto.apa...@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
>>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>>> >>>>> pre...@apache.org>
>>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>>> >>> >>>>> alopresto.apa...@gmail.com>
>>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>> >>>>>
>>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt mailto:joe
>>> >>>>> .w...@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) <
>>> >>>
>>> >>> pwi...@micron.com
>>> >>>>>
>>> >>>>> <mailto:pwi...@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.w...@gmail.com]
>>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>> >>>>> To: dev@nifi.apache.org<mailto:dev@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*
>>> >
>>> >
>>>

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

gt;>> >>>>>
> >>> >>>>> 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  >>> >>>
> >>> >>>  >>> >>>>>
> >>> >>>>> lopre...@apache.org><mailto:alopre...@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
> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
> >>> >>>>> pre...@apache.org>
> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
> >>> > >>> >>>>> alopresto.apa...@gmail.com>
> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
> EF69
> >>> >>>>>
> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne  >>>  >>> >>>>> arka...@hotmail.com><mailto:marka...@hotmail.com>> wrote:
>

Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt]

gt; >>>>> 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
>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>> >>> >>>>> pre...@apache.org>
>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>> >>> >> >>> >>>>> alopresto.apa...@gmail.com>
>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>> EF69
>> >>> >>>>>
>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne > >>> > >>> >>>>> arka...@hotmail.com><mailto:marka...@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.apa...@gmail.com<
>> >>> >>>>> mailto:alopresto.apa...@gmail.com>> alopresto.apa...@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
>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>> >>> >>>>> pre...@apache.org>
>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>> >>> >> >>> >>>>> alopresto.apa...@gmail.com>
>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>> EF69
>> >>> >>>>>
>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt > joe
>> >>> >>>>> .w...@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) <
>> >>> >>>
>> >>> >>> pwi...@micron.com
>> >>> >>>>>
>> >>> >>>>> <mailto:pwi...@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.w...@gmail.com]
>> >>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>> >>> >>>>> To: dev@nifi.apache.org<mailto:dev@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]

mitted."
>>> 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 >> >>> >>>
>>> >>> >>> >> >>> >>>>>
>>> >>> >>>>> lopre...@apache.org><mailto:alopre...@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
>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>>> >>> >>>>> pre...@apache.org>
>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>>> >>> >>> >>> >>>>> alopresto.apa...@gmail.com>
>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>>> EF69
>>> >>> >>>>>
>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne >> >>> >> >>> >>>>> arka...@hotmail.com><mailto:marka...@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.apa...@gmail.com<
>>> >>> >>>>> mailto:alopresto.apa...@gmail.com>>> alopresto.apa...@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
>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo
>>> >>> >>>>> pre...@apache.org>
>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com
>>> >>> >>> >>> >>>>> alopresto.apa...@gmail.com>
>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>>> EF69
>>> >>> >>>>>
>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt >> joe
>>> >>> >>>>> .w...@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) <
>>> >>> >>>
>>> >>> >>> pwi...@micron.com
>>> >>> >>>>>
>>> >>> >>>>> <mailto:pwi...@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.w...@gmail.com]
>>> >>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>> >>> >>>>> To: dev@nifi.apache.org<mailto:dev@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]

so I’m glad we’re
>>>> >>> >>>
>>>> >>> >>> talking
>>>> >>> >>>>>
>>>> >>> >>>>> about it.
>>>> >>> >>>>>
>>>> >>> >>>>> Andy LoPresto
>>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org>
>>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com>
>>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>>>> EF69
>>>> >>> >>>>>
>>>> >>> >>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne >>> >>> >>> >>> >>>>> arka...@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 >>> >>> >>>
>>>> >>> >>> >>> >>> >>>>>
>>>> >>> >>>>> lopre...@apache.org><mailto:alopre...@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 t

Re: Closing in on a NiFi 1.2.0 release?

[Tony Kurc]

> 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 <
> alopre...@apache.org
> >>>> >>> >>>
> >>>> >>> >>>  >>>> >>> >>>>>
> >>>> >>> >>>>> lopre...@apache.org><mailto:alopre...@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
> >>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org> alo
> >>>> >>> >>>>> pre...@apache.org>
> >>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apache@gmail.
> com
> >>>> >>> > >>>> >>> >>>>> alopresto.apa...@gmail.com>
> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
> 2F7D
> >>>> EF69
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <
> marka...@hotmail.com
> >>>> >>>  >>>> >>> >>>>> arka...@hotmail.com><mailto:marka...@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.apa...@gmail.com<
> >>>> >>> >>>>> mailto:alopresto.apa...@gmail.com> >>>> alopresto.apa...@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
> >>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org> alo
> >>>> >>> >>>>> pre...@apache.org>
> >>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apache@gmail.
> com
> >>>> >>> > >>>> >>> >>>>> alopresto.apa...@gmail.com>
> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
> 2F7D
> >>>> EF69
> >>>> >>> >>>>>
> >>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt   >>>> joe
> >>>> >>> >>>>> .w...@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) <
> >>>> >>> >>>
> >>>> >>> >>> pwi...@micron.com
> >>>> >>> >>>>>
> >>>> >>> >>>>> <mailto:pwi...@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.w...@gmail.com]
> >>>> >>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM
> >>>> >>> >>>>> To: dev@nifi.apache.org<mailto:dev@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]

t;>> alopresto.apa...@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 <
>> marka...@hotmail.com
>> >>>> >>> > >>>> >>> >>>>> arka...@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 <
>> alopre...@apache.org
>> >>>> >>> >>>
>> >>>> >>> >>> > >>>> >>> >>>>>
>> >>>> >>> >>>>> lopre...@apache.org><mailto:alopre...@apache.org>> wrote:
>> >>>> >>> >>>>>
>> >

Re: Closing in on a NiFi 1.2.0 release?

[u...@moosheimer.com]

gt;>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> alopre...@apache.org<mailto:alopre...@apache.org>
>>>>>>>>>>>>>>> alopresto.apa...@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 <
>>> marka...@hotmail.com
>>>>>>>>>> >>>>>>>>>>>>>> arka...@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
>

Re: Closing in on a NiFi 1.2.0 release?

[roboh]

Hi,

is there any date set for 1.2.0 release yet? 
We are running into an  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]

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  wrote:
> Hi,
>
> is there any date set for 1.2.0 release yet?
> We are running into an  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]

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  wrote:

Hi,

is there any date set for 1.2.0 release yet?
We are running into an  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]

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  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  wrote:
>>>
>>> Hi,
>>>
>>> is there any date set for 1.2.0 release yet?
>>> We are running into an  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]

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  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  
> 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  wrote:

 Hi,

 is there any date set for 1.2.0 release yet?
 We are running into an  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]

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  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  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  
>> 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  wrote:
>
> Hi,
>
> is there any date set for 1.2.0 release yet?
> We are running into an  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?

[Scott Aslan]

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  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  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 
> 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  wrote:
> 
>  Hi,
> 
>  is there any date set for 1.2.0 release yet?
>  We are running into an  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":
"scottyas...@gmail.com ","linkedin":
"http://www.linkedin.com/in/scottyaslan
"}});*

Re: Closing in on a NiFi 1.2.0 release?

[Joe Witt]

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  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  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  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 
>> 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  wrote:
>> 
>>  Hi,
>> 
>>  is there any date set for 1.2.0 release yet?
>>  We are running into an  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":
> "scottyas...@gmail.com ","linkedin":
> "http://www.linkedin.com/in/scottyaslan
> "}});*

Re: Closing in on a NiFi 1.2.0 release?

[Andrew Lim]

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  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  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  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  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 
>>> 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  wrote:
>>> 
>>> Hi,
>>> 
>>> is there any date set for 1.2.0 release yet?
>>> We are running into an  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":
>> "scottyas...@gmail.com ","linkedin":
>> "http://www.linkedin.com/in/scottyaslan
>> "}});*

Re: Closing in on a NiFi 1.2.0 release?

[Aldrin Piri]

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 
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  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 
> 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  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  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 <
> r...@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  wrote:
> >>>
> >>> Hi,
> >>>
> >>> is there any date set for 1.2.0 release yet?
> >>> We are running into an  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"},"c

Re: Closing in on a NiFi 1.2.0 release?

[Andrew Lim]

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  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 
> 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  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 
>> 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  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  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 <
>> r...@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  wrote:
> 
> Hi,
> 
> is there any date set for 1.2.0 release yet?
> We are running into an  NIFI-3389
>    issue and
>> would
> like
> to
> know when we can expect 1.2.0 release to be available.
> 
> Thanks,
> Robert
> 
> 
> 
> --
>>

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

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

On Tue, May 2, 2017 at 3:42 PM, Andrew Lim  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  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 
>> 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  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 
>>> 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  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  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 <
>>> r...@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  wrote:
>>
>> Hi,
>>
>> is there any date set for 1.2.0 release yet?
>> We are running into an  NIFI-3389
>> 

Re: Closing in on a NiFi 1.2.0 release?

[Andy LoPresto]

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

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

> On May 2, 2017, at 3:51 PM, Bryan Bende  wrote:
> 
> Thanks Drew. These seem like good candidates for the release.
> 
> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim  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  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 
>>> 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  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 
 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  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  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 <
 r...@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'l

Re: Closing in on a NiFi 1.2.0 release?

[Andre]

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  wrote:

> I’ll review & merge as soon as they are available.
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On May 2, 2017, at 3:51 PM, Bryan Bende  wrote:
>
> Thanks Drew. These seem like good candidates for the release.
>
> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim 
> 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  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 
> 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  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 
>
> 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  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 highlight

Re: Closing in on a NiFi 1.2.0 release?

[Andre]

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  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 
> wrote:
>
>> I’ll review & merge as soon as they are available.
>>
>> Andy LoPresto
>> alopre...@apache.org
>> *alopresto.apa...@gmail.com *
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>
>> On May 2, 2017, at 3:51 PM, Bryan Bende  wrote:
>>
>> Thanks Drew. These seem like good candidates for the release.
>>
>> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim 
>> 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  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 
>> 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  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 
>>
>> 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  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 operat

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

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  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  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 
>> wrote:
>>
>>> I’ll review & merge as soon as they are available.
>>>
>>> Andy LoPresto
>>> alopre...@apache.org
>>> *alopresto.apa...@gmail.com *
>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>
>>> On May 2, 2017, at 3:51 PM, Bryan Bende  wrote:
>>>
>>> Thanks Drew. These seem like good candidates for the release.
>>>
>>> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim 
>>> 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  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 
>>> 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  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 
>>>
>>> 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  wrote:
>>>
>>> All,
>>>
>>> Looks lik

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

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  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  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  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 
>>> wrote:
>>>
 I’ll review & merge as soon as they are available.

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

 On May 2, 2017, at 3:51 PM, Bryan Bende  wrote:

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

 On Tue, May 2, 2017 at 3:42 PM, Andrew Lim 
 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  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 >>> >
 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  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 

 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 co

Re: Closing in on a NiFi 1.2.0 release?

[Bryan Bende]

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  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  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  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  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 
 wrote:

> I’ll review & merge as soon as they are available.
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On May 2, 2017, at 3:51 PM, Bryan Bende  wrote:
>
> Thanks Drew. These seem like good candidates for the release.
>
> On Tue, May 2, 2017 at 3:42 PM, Andrew Lim 
> 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  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.apa...@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  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 
>
> 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 v

Re: Closing in on a NiFi 1.2.0 release?

[Joe Gresock]

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


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, May 4, 2017 at 1:20 PM, Bryan Bende  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  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  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  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  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 
>  wrote:
> 
> > I’ll review & merge as soon as they are available.
> >
> > Andy LoPresto
> > alopre...@apache.org
> > *alopresto.apa...@gmail.com *
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On May 2, 2017, at 3:51 PM, Bryan Bende  wrote:
> >
> > Thanks Drew. These seem like good candidates for the release.
> >
> > On Tue, May 2, 2017 at 3:42 PM, Andrew Lim <
> andrewlim.apa...@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 
> 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.apa...@gm