nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Bateman <r...@windofkeltia.com>
Subject Re: Closing in on a NiFi 1.2.0 release?
Date Wed, 08 Mar 2017 19:43:23 GMT
+1 for component versioning in NiFi 1.2!

On 03/08/2017 12:40 PM, James Wing wrote:
> Bryan, I'm 100% in favor of you and Matt Gilman doing all the hard work.
> Oh, and uh... thanks! :)
>
> So the alternatives are:
> a.) Release 1.2.0 sooner (?), but without component versioning
> b.) Delay 1.2.0 (?) to incorporate component versioning
>
> Will the NAR plugin alone commit us to all of the component versioning work
> in 1.2, or will the new NAR format be backward-compatible?  Or is the
> question more about the strategy for 1.2.0?
>
>
> Thanks,
>
> James
>
> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bbende@gmail.com> wrote:
>
>> Just wanted to mention that one of the JIRAs tagged for 1.2.0 is
>> NIFI-3380 "support multiple versions of the same component" [1] and
>> I've been working with Matt Gilman on this [2]. The functionality is
>> very close to being done and I think we should get this into the 1.2.0
>> release.
>>
>> In order to fully leverage the versioned components we will need to
>> release an updated Maven NAR plugin, so we would do that first and
>> then release 1.2.0 using the new plugin. If everyone is on-board with
>> this plan then I can advise when we are ready to release the new
>> plugin which would be soon.
>>
>> [1] https://issues.apache.org/jira/browse/NIFI-3380
>> [2] https://github.com/bbende/nifi/tree/NIFI-3380
>>
>> On Fri, Mar 3, 2017 at 9:56 AM, Joe Gresock <jgresock@gmail.com> wrote:
>>> This is good discussion that should continue, but what about the original
>>> intent of Joe's post?  "Is there any reason folks can think of to hold
>> off
>>> on a 1.2.0 release?"
>>>
>>> On Fri, Mar 3, 2017 at 1:45 PM, Mark Payne <markap14@hotmail.com> wrote:
>>>
>>>> Andy,
>>>>
>>>> Sorry, i haven't responded to this thread in over a week, but I think
>> it's
>>>> important to keep going.
>>>>
>>>> I just clicked "Cancel Patch" on one of my ticket that has a patch
>>>> available to see which state it returned to.
>>>> It did in fact go back to Open. Which I agree is less than ideal. Though
>>>> we could certainly have a process
>>>> by which we change the status to "In Progress" after canceling the
>> patch.
>>>> I guess where my viewpoint differs from yours is in the meaning of "In
>>>> Review." Let's say that you submit a
>>>> patch for a JIRA. I then review it and find that it needs some work -
>>>> let's say there's an issue with licensing
>>>> not being properly accounted for, for instance. At that point, I no
>> longer
>>>> consider the patch that you provided
>>>> to be "In Review." I believe the patch should be canceled, and you will
>>>> need to submit a new patch. I guess
>>>> that I view a patch as being an immutable entity.
>>>>
>>>>
>>>>
>>>>
>>>> On Feb 24, 2017, at 7:26 PM, Andy LoPresto <alopresto@apache.org
>> <mailto:a
>>>> lopresto@apache.org>> wrote:
>>>>
>>>> Mark,
>>>>
>>>> Your understanding of “Patch Available” certainly makes sense and it
>>>> explains why you approach the process the way you do. I have a slightly
>>>> different personal understanding of “Patch Available” — I read it to
>> mean
>>>> “the person responsible for this Jira has contributed code they feel
>> solves
>>>> the issue.” A review will (hopefully) determine if that assertion is
>>>> correct and complete. I think we kind of agree on "my viewpoint is
>> simply
>>>> that "Patch Available" means "Awaiting Review" or "In Review.”” but I
>> see
>>>> “In Review” as a potentially iterative process — it could be on the
>> second
>>>> pass of the contributor responding to comments, but it’s still “In
>> Review”
>>>> in my eyes. I don’t know that the granularity of Jira supports the
>> specific
>>>> workflow states of “been reviewed once but not complete/accepted yet”.
>>>>
>>>> What state does “Cancel Patch” result in? If it just reverts to “Open”,
>> I
>>>> don’t see the value because that obfuscates the difference between a
>> Jira
>>>> that hasn’t even been touched and one that has 90% of the code done. I
>>>> agree we should make the RM’s job easier, but I also think it doesn’t
>> help
>>>> the visibility for reviewers to see a Jira marked as “open” when there
>> is
>>>> the potential for that patch to be ready for merge in a very short
>> amount
>>>> of time.
>>>>
>>>> I think these conversations will ultimately help us narrow in on shared
>>>> definitions that make sense to everyone though, so I’m glad we’re
>> talking
>>>> about it.
>>>>
>>>> Andy LoPresto
>>>> alopresto@apache.org<mailto:alopresto@apache.org>
>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com>
>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>
>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <markap14@hotmail.com<mailto:m
>>>> arkap14@hotmail.com>> wrote:
>>>>
>>>> Andy,
>>>>
>>>> If the reviewer is looking for clarification, then it may make sense to
>>>> leave the JIRA in "Patch Available" state
>>>> as you suggest. If there are minor fixes needed, though, then the patch
>> is
>>>> not ready. In JIRA, the verbiage for
>>>> Cancel Patch says "The patch is not yet ready to be committed." So if
>>>> minor fixes are needed, then I believe
>>>> it is appropriate to Cancel Patch. Once those changes (minor or not) are
>>>> made and the PR updated, then the
>>>> PR needs review again and the status should be changed back to "Patch
>>>> Available" again.
>>>>
>>>> I guess my viewpoint is simply that "Patch Available" means "Awaiting
>>>> Review" or "In Review." If it is awaiting
>>>> changes of some kind and won't be merged as-is, then we should Cancel
>>>> Patch.
>>>>
>>>> Do you or others have differing views on the meaning of "Patch
>> Available"?
>>>> Thanks
>>>> -Mark
>>>>
>>>>
>>>> On Feb 24, 2017, at 3:27 PM, Andy LoPresto <alopresto@apache.org
>> <mailto:a
>>>> lopresto@apache.org><mailto:alopresto@apache.org>> wrote:
>>>>
>>>> Mark,
>>>>
>>>> I like your point about updating the Jira with the Fix Version at the
>> time
>>>> the PR review begins (or when the PR is submitted, if the contributor is
>>>> aware of this process). I think it’s better than waiting for the merge,
>> as
>>>> I proposed before.
>>>>
>>>> I agree that the reviewer is responsible for keeping the Jira updated in
>>>> line with their work. I don’t know if I am on the same page as you for
>>>> “Cancel Patch” if the PR needs changes; sometimes these are minor fixes
>> or
>>>> just looking for clarification from the contributor, and I don’t think
>> that
>>>> warrants canceling the availability of the patch. If they are major
>>>> architectural changes, then that makes more sense to me.
>>>>
>>>> Andy LoPresto
>>>> alopresto@apache.org<mailto:alopresto@apache.org><mailto:alo
>>>> presto@apache.org>
>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com><mailto:
>>>> alopresto.apache@gmail.com>
>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>
>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <markap14@hotmail.com<mailto:m
>>>> arkap14@hotmail.com><mailto:markap14@hotmail.com>> wrote:
>>>>
>>>> Personally, I am afraid that if we don't set a Fix Version on JIRA's,
>> that
>>>> some PR's will be lost
>>>> or stalled. I rarely go to github and start looking through the PRs.
>>>> Instead, I go to JIRA and look
>>>> at what is assigned with a fixVersion of the next release. Then I'll go
>>>> and review JIRA's that are
>>>> in a state of "Patch Available." Even then I often come across many PR's
>>>> that have already been
>>>> reviewed by one or more other committers and are awaiting updates.
>>>>
>>>> So I propose that we address this slightly differently. I believe that
>> we
>>>> should assign a Fix Version to
>>>> a JIRA whenever a PR is submitted. Then, whenever a committer reviews a
>>>> PR, he/she should be
>>>> responsible for updating the JIRA. If the PR is merged then the JIRA
>>>> should be resolved as Fixed.
>>>> But if the PR is not merged because some changes are needed, the
>> reviewer
>>>> should then go back to
>>>> the JIRA and click 'Cancel Patch'. We are typically very good about
>>>> resolving as fixed once a PR is
>>>> merged, but we don't typically cancel the patch otherwise.
>>>>
>>>> If we followed this workflow, then a Release Manager (or anyone else)
>> can
>>>> easily see which tickets
>>>> need to be reviewed before a release happens and which ones can be
>> pushed
>>>> out because they
>>>> are not ready (even if a PR has been posted). It also makes it much
>> easier
>>>> for reviewers to quickly
>>>> know which tickets are awaiting review.
>>>>
>>>> Thoughts?
>>>>
>>>> -Mark
>>>>
>>>>
>>>> On Feb 23, 2017, at 3:37 AM, Andy LoPresto <alopresto.apache@gmail.com<
>>>> mailto:alopresto.apache@gmail.com><mailto:alopresto.apache@gmail.com>>
>>>> wrote:
>>>>
>>>> As someone who has surely been guilty of optimistically setting fix
>>>> versions and then not meeting them, I second Joe's point about it
>> holding
>>>> up releases. Better to get the PR out, reviewed, and merged *before*
>>>> setting the fix version in my opinion.
>>>>
>>>> Andy LoPresto
>>>> alopresto@apache.org<mailto:alopresto@apache.org><mailto:alo
>>>> presto@apache.org>
>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com><mailto:
>>>> alopresto.apache@gmail.com>
>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>
>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.witt@gmail.com<mailto:joe
>>>> .witt@gmail.com>> wrote:
>>>>
>>>> Peter,
>>>>
>>>> This is just my preference so discussion is certainly open.  But the
>>>> way I see it we should not set the fix version on JIRAs unless they
>>>> really should block a release without resolution or if due to some
>>>> roadmap/planning/discussion it is a new feature/improvement that is
>>>> tied to a release.  Otherwise, for the many things which pop up
>>>> throughout a given release cycle they should be avoided.  That is to
>>>> say the majority of the time we'd avoid fix versions until the act of
>>>> merging a contribution which also means it has been reviewed.
>>>>
>>>>  From the release management point of view:
>>>> This approach helps greatly as until now it is has been really
>>>> difficult and time consuming to pull together/close down a release as
>>>> pretty much anyone can set these fix versions and make it appear as
>>>> though the release is not ready when in reality it is perfectly
>>>> releasable as-is but might miss out on some contribs that someone
>>>> would like to see in the release but has as of yet not gotten the PR
>>>> and/or review traction necessary.
>>>>
>>>>  From the contributor point of view:
>>>> If someone makes a contribution they obviously want that code to end
>>>> up in a release.  But being an RTC community we need and want peer
>>>> review before the code is submitted.  Some contributions are frankly
>>>> hard to get peer review on or simply take time for someone to
>>>> volunteer to do.  PRs which are difficult to test, lack testing, are
>>>> related to systems or environments which are not easily replicated,
>>>> etc.. are inherently harder to get peer review for.  Also, the
>>>> community has grown quite rapidly and sometimes the hygiene of a given
>>>> PR isn't great.  So our 'patch available' and 'open PR' count ticks
>>>> up.  We need reviews/feedback as much as we need contributions so it
>>>> is important for folks that want those contributions in to build
>>>> meritocracy as well in reviewing others contributions.  This helps
>>>> build a network of contributors/reviewers and improves the timeliness
>>>> of reviews.  Long story short here is that because at times PRs can
>>>> sit too long sometimes people put a fix version on the JIRA so it acts
>>>> as a sort of 'gating function' on the release.  This I am saying is
>>>> the practice that should not occur (given the thoughts above).  We
>>>> should instead take the issue of how to more effectively
>>>> triage/review/provide feedback/and manage expectations for
>>>> contributions so contributors don't feel like their stuff will just
>>>> sit forever.
>>>>
>>>> Does that make sense and seem fair?
>>>>
>>>> Thanks
>>>> Joe
>>>>
>>>>
>>>>
>>>> On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) <
>> pwicks@micron.com
>>>> <mailto:pwicks@micron.com>> wrote:
>>>> Just for clarification, "We really need to avoid the practice of setting
>>>> fix versions without traction", would mean don't set a version number
>> until
>>>> after we've submitted a PR? Until after the PR has been closed? Other?
>>>>
>>>> Thanks,
>>>> Peter
>>>>
>>>> -----Original Message-----
>>>> From: Joe Witt [mailto:joe.witt@gmail.com]
>>>> Sent: Wednesday, February 22, 2017 12:55 PM
>>>> To: dev@nifi.apache.org<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*


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message