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