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