Bryan How are things looking for what you updated on? The nar plugin of course is out.
We got another question on the user list for 1.2 so I just want to make sure we're closing in. I'll start doing the JIRA whipping. Thanks JOe On Mon, Mar 13, 2017 at 3:22 PM, Bryan Bende <bbe...@gmail.com> wrote: > Just a quick update on this discussion... > > On Friday we were able to post an initial PR for the component > versioning work [1]. > > I believe we are ready to move forward with a release of the NAR Maven > plugin, there are three tickets to be included in the release [2]. > > If there are no objections, I can take on the release manager duties > for the NAR plugin, and can begin to kick off the process tomorrow. > > -Bryan > > [1] https://github.com/apache/nifi/pull/1585 > [2] > https://issues.apache.org/jira/browse/NIFI-3589?jql=fixVersion%20%3D%20nifi-nar-maven-plugin-1.2.0%20AND%20project%20%3D%20NIFI > > On Wed, Mar 8, 2017 at 6:19 PM, James Wing <jvw...@gmail.com> wrote: >> +1 for component versioning in 1.2.0, it will be a solid capstone feature. >> And I agree it's probably not holding up the release. >> >> Thanks, >> >> James >> >> On Wed, Mar 8, 2017 at 1:21 PM, Bryan Bende <bbe...@gmail.com> wrote: >> >>> James, >>> >>> No problem :) >>> >>> I was mostly just suggesting an overall strategy... >>> >>> Usually when we start closing in on a release we go through the JIRAs >>> tagged for that release and try to figure out which ones can be moved >>> to a future release, and which ones the community is actually working >>> on and close to being ready. Currently we have 39 unresolved JIRAs >>> that are tagged as 1.2, one of which is NIFI-3380, and I figured if >>> someone looked at the ticket it might look like no work had been done >>> and figure that it can just be moved to next release, so I just wanted >>> to mention that it is very close to being ready was still hoping for >>> it be in 1.2, unless there was strong opinion to move on without it. >>> Even if we moved on without it, I believe there is still a bit of work >>> to do in that we still need a release manager and we need to decide >>> what to do with the 39 JIRAs. >>> >>> As far as the new NAR plugin and how things will work... >>> >>> The changes to the NAR plugin add additional information to the >>> MANIFEST file in the NAR. Technically existing NiFi would have no >>> problem reading the new MANIFEST file because no entries are being >>> removed, and the branch I have with the component versioning code for >>> NiFi could also run against old NARs that don't have the new entries, >>> you just see everything as being "unversioned" and can't actually make >>> use of the new capabilities. We'll always have to be able to run older >>> NARs because there are tons of custom NARs out there that have not >>> been (and may never be) rebuilt with the newer version of the plugin, >>> which is fine, they only need to be rebuilt if someone wants to run >>> two versions of that NAR at the same time. >>> >>> Happy to elaborate more on any of the component versioning work if >>> anyone is interested. >>> >>> Thanks, >>> >>> Bryan >>> >>> >>> On Wed, Mar 8, 2017 at 2:43 PM, Russell Bateman <r...@windofkeltia.com> >>> wrote: >>> > +1 for component versioning in NiFi 1.2! >>> > >>> > >>> > On 03/08/2017 12:40 PM, James Wing wrote: >>> >> >>> >> Bryan, I'm 100% in favor of you and Matt Gilman doing all the hard work. >>> >> Oh, and uh... thanks! :) >>> >> >>> >> So the alternatives are: >>> >> a.) Release 1.2.0 sooner (?), but without component versioning >>> >> b.) Delay 1.2.0 (?) to incorporate component versioning >>> >> >>> >> Will the NAR plugin alone commit us to all of the component versioning >>> >> work >>> >> in 1.2, or will the new NAR format be backward-compatible? Or is the >>> >> question more about the strategy for 1.2.0? >>> >> >>> >> >>> >> Thanks, >>> >> >>> >> James >>> >> >>> >> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bbe...@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 <jgres...@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 <marka...@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 <alopre...@apache.org >>> >>> >>> >>> <mailto:a >>> >>>>> >>> >>>>> lopre...@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 >>> >>>>> 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 <marka...@hotmail.com >>> <mailto:m >>> >>>>> 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 >>> >>> >>> >>> <mailto:a >>> >>>>> >>> >>>>> 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 >>> ><mailto: >>> >>>>> 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 >>> <mailto:m >>> >>>>> 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 >>> ><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 <joe.w...@gmail.com<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* >>> > >>> > >>>
