+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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected] > >>> > >>> <mailto:a > >>>>> > >>>>> [email protected]>> 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 > >>>>> [email protected]<mailto:[email protected]> > >>>>> [email protected]<mailto:[email protected]> > >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >>>>> > >>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <[email protected] > <mailto:m > >>>>> [email protected]>> 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 <[email protected] > >>> > >>> <mailto:a > >>>>> > >>>>> [email protected]><mailto:[email protected]>> 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 > >>>>> [email protected]<mailto:[email protected]><mailto:alo > >>>>> [email protected]> > >>>>> [email protected]<mailto:[email protected] > ><mailto: > >>>>> [email protected]> > >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >>>>> > >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <[email protected] > <mailto:m > >>>>> [email protected]><mailto:[email protected]>> 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 < > [email protected]< > >>>>> mailto:[email protected]><mailto:[email protected] > >> > >>>>> 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 > >>>>> [email protected]<mailto:[email protected]><mailto:alo > >>>>> [email protected]> > >>>>> [email protected]<mailto:[email protected] > ><mailto: > >>>>> [email protected]> > >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >>>>> > >>>>> On Feb 22, 2017, at 19:39, Joe Witt <[email protected]<mailto:joe > >>>>> [email protected]>> 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) < > >>> > >>> [email protected] > >>>>> > >>>>> <mailto:[email protected]>> 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:[email protected]] > >>>>> Sent: Wednesday, February 22, 2017 12:55 PM > >>>>> To: [email protected]<mailto:[email protected]> > >>>>> 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* > > > > >
