Twitter processor stays. Great news! Thanks to Joey! Mit freundlichen Grüßen / best regards Kay-Uwe Moosheimer
> Am 11.04.2017 um 21:20 schrieb Joe Witt <[email protected]>: > > Team, > > Couple of good news updates on the release front is we're in the teens > on number of tickets AND Joey Frazee figured out a way to clean up the > twitter/json.org Cat-X dependency issue so our twitter processor > stays! > > Will keep working the march down to 0 tickets. A lot of good stuff in > this release so this should be a fun one! > > Thanks > Joe > >> On Tue, Apr 4, 2017 at 7:37 PM, Tony Kurc <[email protected]> wrote: >> Joe et. al, >> I think this one is close too (mainly dotting i's and crossing t's on >> license and notice) >> >> https://issues.apache.org/jira/browse/NIFI-3586 >> >>> On Tue, Apr 4, 2017 at 2:23 PM, Joe Witt <[email protected]> wrote: >>> >>> Team, >>> >>> Another update on efforts to close-in on the NiFi 1.2.0 release. >>> We're below 20 JIRAs now and there has been good momentum. A couple >>> items still need work but look really important and then there is >>> review traction/feedback cycles. Will just keep monitoring it and >>> actively defending to close the loop on 1.2.0 until we're there. >>> >>> Thanks >>> Joe >>> >>>> On Tue, Mar 28, 2017 at 9:45 AM, Joe Witt <[email protected]> wrote: >>>> Team, >>>> >>>> Status of JIRA cleanup toward an Apache NiFi 1.2.0 release candidate >>>> which Mr Bende has so wonderfully volunteered to RM: >>>> >>>> There are 20 open JIRAs as of now. >>>> >>>> 12 of 20 have PRs that appear ready/close to ready. >>>> >>>> One pattern I noticed quite a bit on the 1.2.0 release is heavy usage >>>> of 'squatter JIRAs' whereby someone makes a JIRA and with or without >>>> any review traction and for non blocking issues sets the fix version. >>>> This practice should be avoided. The fix version should be reserved >>>> for once there is a blocker item or there is something with a patch >>>> contributed and review progress closing in on a merge. >>>> >>>> One of them means we need to punt the Twitter processor most likely. >>>> Don't believe there were new releases to resolve that licensing issue >>>> by the third party dependency. I'll take that on. >>>> https://issues.apache.org/jira/browse/NIFI-3089 >>>> >>>> Two of them are build failure issues which means windows and linux >>>> builds break (highly repeatable): >>>> https://issues.apache.org/jira/browse/NIFI-3441 >>>> https://issues.apache.org/jira/browse/NIFI-3440 >>>> >>>> A couple need to either be moved out or addressed for implementation >>>> or review but it isn't clear to me their status: >>>> https://issues.apache.org/jira/browse/NIFI-3155 >>>> https://issues.apache.org/jira/browse/NIFI-1280 >>>> https://issues.apache.org/jira/browse/NIFI-2656 >>>> https://issues.apache.org/jira/browse/NIFI-2886 >>>> >>>> Some are really important and being worked still: >>>> https://issues.apache.org/jira/browse/NIFI-3520 >>>> >>>> Thanks >>>> Joe >>>> >>>>> On Wed, Mar 22, 2017 at 9:12 PM, Joe Witt <[email protected]> wrote: >>>>> Sweet! I'll take that deal all day. Thanks Bryan! >>>>> >>>>>> On Wed, Mar 22, 2017 at 8:26 PM, Bryan Bende <[email protected]> wrote: >>>>>> Joe, >>>>>> >>>>>> As of today I believe the PR for NIFI-3380 (component versioning) >>> should >>>>>> address all of the code review feedback and is in a good place. >>>>>> >>>>>> Would like to run through a few more tests tomorrow, and baring any >>>>>> additional feedback from reviewers, we could possibly merge that >>> tomorrow. >>>>>> That PR will also bump master to use the newly released NAR plugin. >>>>>> >>>>>> Since I got a warm-up with NAR plugin, I don't mind taking on release >>>>>> manager duties for 1.2, although I would still like help on the JIRA >>>>>> whipping. I imagine there's still a bit of work to narrow down the >>>>>> remaining tickets. >>>>>> >>>>>> -Bryan >>>>>> >>>>>>> On Wed, Mar 22, 2017 at 7:35 PM Joe Witt <[email protected]> wrote: >>>>>>> >>>>>>> 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 <[email protected]> >>> 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 <[email protected]> >>> 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 <[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: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 < >>> [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:alopresto.apache@gmail. >>> com >>>>>>>>>>> <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:alopresto.apache@gmail. >>> com >>>>>>>>>>> <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* >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>>>> -- >>>>>> Sent from Gmail Mobile >>>
