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 <joe.w...@gmail.com> 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 <joe.w...@gmail.com> wrote: >> Sweet! I'll take that deal all day. Thanks Bryan! >> >> On Wed, Mar 22, 2017 at 8:26 PM, Bryan Bende <bbe...@gmail.com> 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 <joe.w...@gmail.com> 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 <bbe...@gmail.com> wrote: >>>> > Just a quick update on this discussion... >>>> > >>>> > On Friday we were able to post an initial PR for the component >>>> > versioning work [1]. >>>> > >>>> > I believe we are ready to move forward with a release of the NAR Maven >>>> > plugin, there are three tickets to be included in the release [2]. >>>> > >>>> > If there are no objections, I can take on the release manager duties >>>> > for the NAR plugin, and can begin to kick off the process tomorrow. >>>> > >>>> > -Bryan >>>> > >>>> > [1] https://github.com/apache/nifi/pull/1585 >>>> > [2] >>>> https://issues.apache.org/jira/browse/NIFI-3589?jql=fixVersion%20%3D%20nifi-nar-maven-plugin-1.2.0%20AND%20project%20%3D%20NIFI >>>> > >>>> > On Wed, Mar 8, 2017 at 6:19 PM, James Wing <jvw...@gmail.com> wrote: >>>> >> +1 for component versioning in 1.2.0, it will be a solid capstone >>>> feature. >>>> >> And I agree it's probably not holding up the release. >>>> >> >>>> >> Thanks, >>>> >> >>>> >> James >>>> >> >>>> >> On Wed, Mar 8, 2017 at 1:21 PM, Bryan Bende <bbe...@gmail.com> wrote: >>>> >> >>>> >>> James, >>>> >>> >>>> >>> No problem :) >>>> >>> >>>> >>> I was mostly just suggesting an overall strategy... >>>> >>> >>>> >>> Usually when we start closing in on a release we go through the JIRAs >>>> >>> tagged for that release and try to figure out which ones can be moved >>>> >>> to a future release, and which ones the community is actually working >>>> >>> on and close to being ready. Currently we have 39 unresolved JIRAs >>>> >>> that are tagged as 1.2, one of which is NIFI-3380, and I figured if >>>> >>> someone looked at the ticket it might look like no work had been done >>>> >>> and figure that it can just be moved to next release, so I just wanted >>>> >>> to mention that it is very close to being ready was still hoping for >>>> >>> it be in 1.2, unless there was strong opinion to move on without it. >>>> >>> Even if we moved on without it, I believe there is still a bit of work >>>> >>> to do in that we still need a release manager and we need to decide >>>> >>> what to do with the 39 JIRAs. >>>> >>> >>>> >>> As far as the new NAR plugin and how things will work... >>>> >>> >>>> >>> The changes to the NAR plugin add additional information to the >>>> >>> MANIFEST file in the NAR. Technically existing NiFi would have no >>>> >>> problem reading the new MANIFEST file because no entries are being >>>> >>> removed, and the branch I have with the component versioning code for >>>> >>> NiFi could also run against old NARs that don't have the new entries, >>>> >>> you just see everything as being "unversioned" and can't actually make >>>> >>> use of the new capabilities. We'll always have to be able to run older >>>> >>> NARs because there are tons of custom NARs out there that have not >>>> >>> been (and may never be) rebuilt with the newer version of the plugin, >>>> >>> which is fine, they only need to be rebuilt if someone wants to run >>>> >>> two versions of that NAR at the same time. >>>> >>> >>>> >>> Happy to elaborate more on any of the component versioning work if >>>> >>> anyone is interested. >>>> >>> >>>> >>> Thanks, >>>> >>> >>>> >>> Bryan >>>> >>> >>>> >>> >>>> >>> On Wed, Mar 8, 2017 at 2:43 PM, Russell Bateman <r...@windofkeltia.com >>>> > >>>> >>> wrote: >>>> >>> > +1 for component versioning in NiFi 1.2! >>>> >>> > >>>> >>> > >>>> >>> > On 03/08/2017 12:40 PM, James Wing wrote: >>>> >>> >> >>>> >>> >> Bryan, I'm 100% in favor of you and Matt Gilman doing all the hard >>>> work. >>>> >>> >> Oh, and uh... thanks! :) >>>> >>> >> >>>> >>> >> So the alternatives are: >>>> >>> >> a.) Release 1.2.0 sooner (?), but without component versioning >>>> >>> >> b.) Delay 1.2.0 (?) to incorporate component versioning >>>> >>> >> >>>> >>> >> Will the NAR plugin alone commit us to all of the component >>>> versioning >>>> >>> >> work >>>> >>> >> in 1.2, or will the new NAR format be backward-compatible? Or is >>>> the >>>> >>> >> question more about the strategy for 1.2.0? >>>> >>> >> >>>> >>> >> >>>> >>> >> Thanks, >>>> >>> >> >>>> >>> >> James >>>> >>> >> >>>> >>> >> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bbe...@gmail.com> >>>> wrote: >>>> >>> >> >>>> >>> >>> Just wanted to mention that one of the JIRAs tagged for 1.2.0 is >>>> >>> >>> NIFI-3380 "support multiple versions of the same component" [1] and >>>> >>> >>> I've been working with Matt Gilman on this [2]. The functionality >>>> is >>>> >>> >>> very close to being done and I think we should get this into the >>>> 1.2.0 >>>> >>> >>> release. >>>> >>> >>> >>>> >>> >>> In order to fully leverage the versioned components we will need to >>>> >>> >>> release an updated Maven NAR plugin, so we would do that first and >>>> >>> >>> then release 1.2.0 using the new plugin. If everyone is on-board >>>> with >>>> >>> >>> this plan then I can advise when we are ready to release the new >>>> >>> >>> plugin which would be soon. >>>> >>> >>> >>>> >>> >>> [1] https://issues.apache.org/jira/browse/NIFI-3380 >>>> >>> >>> [2] https://github.com/bbende/nifi/tree/NIFI-3380 >>>> >>> >>> >>>> >>> >>> On Fri, Mar 3, 2017 at 9:56 AM, Joe Gresock <jgres...@gmail.com> >>>> >>> wrote: >>>> >>> >>>> >>>> >>> >>>> This is good discussion that should continue, but what about the >>>> >>> >>>> original >>>> >>> >>>> intent of Joe's post? "Is there any reason folks can think of to >>>> hold >>>> >>> >>> >>>> >>> >>> off >>>> >>> >>>> >>>> >>> >>>> on a 1.2.0 release?" >>>> >>> >>>> >>>> >>> >>>> On Fri, Mar 3, 2017 at 1:45 PM, Mark Payne <marka...@hotmail.com> >>>> >>> wrote: >>>> >>> >>>> >>>> >>> >>>>> Andy, >>>> >>> >>>>> >>>> >>> >>>>> Sorry, i haven't responded to this thread in over a week, but I >>>> think >>>> >>> >>> >>>> >>> >>> it's >>>> >>> >>>>> >>>> >>> >>>>> important to keep going. >>>> >>> >>>>> >>>> >>> >>>>> I just clicked "Cancel Patch" on one of my ticket that has a >>>> patch >>>> >>> >>>>> available to see which state it returned to. >>>> >>> >>>>> It did in fact go back to Open. Which I agree is less than ideal. >>>> >>> >>>>> Though >>>> >>> >>>>> we could certainly have a process >>>> >>> >>>>> by which we change the status to "In Progress" after canceling >>>> the >>>> >>> >>> >>>> >>> >>> patch. >>>> >>> >>>>> >>>> >>> >>>>> I guess where my viewpoint differs from yours is in the meaning >>>> of >>>> >>> "In >>>> >>> >>>>> Review." Let's say that you submit a >>>> >>> >>>>> patch for a JIRA. I then review it and find that it needs some >>>> work - >>>> >>> >>>>> let's say there's an issue with licensing >>>> >>> >>>>> not being properly accounted for, for instance. At that point, I >>>> no >>>> >>> >>> >>>> >>> >>> longer >>>> >>> >>>>> >>>> >>> >>>>> consider the patch that you provided >>>> >>> >>>>> to be "In Review." I believe the patch should be canceled, and >>>> you >>>> >>> will >>>> >>> >>>>> need to submit a new patch. I guess >>>> >>> >>>>> that I view a patch as being an immutable entity. >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> On Feb 24, 2017, at 7:26 PM, Andy LoPresto <alopre...@apache.org >>>> >>> >>> >>>> >>> >>> <mailto:a >>>> >>> >>>>> >>>> >>> >>>>> lopre...@apache.org>> wrote: >>>> >>> >>>>> >>>> >>> >>>>> Mark, >>>> >>> >>>>> >>>> >>> >>>>> Your understanding of “Patch Available” certainly makes sense >>>> and it >>>> >>> >>>>> explains why you approach the process the way you do. I have a >>>> >>> slightly >>>> >>> >>>>> different personal understanding of “Patch Available” — I read >>>> it to >>>> >>> >>> >>>> >>> >>> mean >>>> >>> >>>>> >>>> >>> >>>>> “the person responsible for this Jira has contributed code they >>>> feel >>>> >>> >>> >>>> >>> >>> solves >>>> >>> >>>>> >>>> >>> >>>>> the issue.” A review will (hopefully) determine if that >>>> assertion is >>>> >>> >>>>> correct and complete. I think we kind of agree on "my viewpoint >>>> is >>>> >>> >>> >>>> >>> >>> simply >>>> >>> >>>>> >>>> >>> >>>>> that "Patch Available" means "Awaiting Review" or "In Review.”” >>>> but I >>>> >>> >>> >>>> >>> >>> see >>>> >>> >>>>> >>>> >>> >>>>> “In Review” as a potentially iterative process — it could be on >>>> the >>>> >>> >>> >>>> >>> >>> second >>>> >>> >>>>> >>>> >>> >>>>> pass of the contributor responding to comments, but it’s still >>>> “In >>>> >>> >>> >>>> >>> >>> Review” >>>> >>> >>>>> >>>> >>> >>>>> in my eyes. I don’t know that the granularity of Jira supports >>>> the >>>> >>> >>> >>>> >>> >>> specific >>>> >>> >>>>> >>>> >>> >>>>> workflow states of “been reviewed once but not complete/accepted >>>> >>> yet”. >>>> >>> >>>>> >>>> >>> >>>>> What state does “Cancel Patch” result in? If it just reverts to >>>> >>> “Open”, >>>> >>> >>> >>>> >>> >>> I >>>> >>> >>>>> >>>> >>> >>>>> don’t see the value because that obfuscates the difference >>>> between a >>>> >>> >>> >>>> >>> >>> Jira >>>> >>> >>>>> >>>> >>> >>>>> that hasn’t even been touched and one that has 90% of the code >>>> done. >>>> >>> I >>>> >>> >>>>> agree we should make the RM’s job easier, but I also think it >>>> doesn’t >>>> >>> >>> >>>> >>> >>> help >>>> >>> >>>>> >>>> >>> >>>>> the visibility for reviewers to see a Jira marked as “open” when >>>> >>> there >>>> >>> >>> >>>> >>> >>> is >>>> >>> >>>>> >>>> >>> >>>>> the potential for that patch to be ready for merge in a very >>>> short >>>> >>> >>> >>>> >>> >>> amount >>>> >>> >>>>> >>>> >>> >>>>> of time. >>>> >>> >>>>> >>>> >>> >>>>> I think these conversations will ultimately help us narrow in on >>>> >>> shared >>>> >>> >>>>> definitions that make sense to everyone though, so I’m glad we’re >>>> >>> >>> >>>> >>> >>> talking >>>> >>> >>>>> >>>> >>> >>>>> about it. >>>> >>> >>>>> >>>> >>> >>>>> Andy LoPresto >>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org> >>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D >>>> EF69 >>>> >>> >>>>> >>>> >>> >>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <marka...@hotmail.com >>>> >>> <mailto:m >>>> >>> >>>>> arka...@hotmail.com>> wrote: >>>> >>> >>>>> >>>> >>> >>>>> Andy, >>>> >>> >>>>> >>>> >>> >>>>> If the reviewer is looking for clarification, then it may make >>>> sense >>>> >>> to >>>> >>> >>>>> leave the JIRA in "Patch Available" state >>>> >>> >>>>> as you suggest. If there are minor fixes needed, though, then the >>>> >>> patch >>>> >>> >>> >>>> >>> >>> is >>>> >>> >>>>> >>>> >>> >>>>> not ready. In JIRA, the verbiage for >>>> >>> >>>>> Cancel Patch says "The patch is not yet ready to be committed." >>>> So if >>>> >>> >>>>> minor fixes are needed, then I believe >>>> >>> >>>>> it is appropriate to Cancel Patch. Once those changes (minor or >>>> not) >>>> >>> >>>>> are >>>> >>> >>>>> made and the PR updated, then the >>>> >>> >>>>> PR needs review again and the status should be changed back to >>>> "Patch >>>> >>> >>>>> Available" again. >>>> >>> >>>>> >>>> >>> >>>>> I guess my viewpoint is simply that "Patch Available" means >>>> "Awaiting >>>> >>> >>>>> Review" or "In Review." If it is awaiting >>>> >>> >>>>> changes of some kind and won't be merged as-is, then we should >>>> Cancel >>>> >>> >>>>> Patch. >>>> >>> >>>>> >>>> >>> >>>>> Do you or others have differing views on the meaning of "Patch >>>> >>> >>> >>>> >>> >>> Available"? >>>> >>> >>>>> >>>> >>> >>>>> Thanks >>>> >>> >>>>> -Mark >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> On Feb 24, 2017, at 3:27 PM, Andy LoPresto <alopre...@apache.org >>>> >>> >>> >>>> >>> >>> <mailto:a >>>> >>> >>>>> >>>> >>> >>>>> lopre...@apache.org><mailto:alopre...@apache.org>> wrote: >>>> >>> >>>>> >>>> >>> >>>>> Mark, >>>> >>> >>>>> >>>> >>> >>>>> I like your point about updating the Jira with the Fix Version >>>> at the >>>> >>> >>> >>>> >>> >>> time >>>> >>> >>>>> >>>> >>> >>>>> the PR review begins (or when the PR is submitted, if the >>>> contributor >>>> >>> >>>>> is >>>> >>> >>>>> aware of this process). I think it’s better than waiting for the >>>> >>> merge, >>>> >>> >>> >>>> >>> >>> as >>>> >>> >>>>> >>>> >>> >>>>> I proposed before. >>>> >>> >>>>> >>>> >>> >>>>> I agree that the reviewer is responsible for keeping the Jira >>>> updated >>>> >>> >>>>> in >>>> >>> >>>>> line with their work. I don’t know if I am on the same page as >>>> you >>>> >>> for >>>> >>> >>>>> “Cancel Patch” if the PR needs changes; sometimes these are minor >>>> >>> fixes >>>> >>> >>> >>>> >>> >>> or >>>> >>> >>>>> >>>> >>> >>>>> just looking for clarification from the contributor, and I don’t >>>> >>> think >>>> >>> >>> >>>> >>> >>> that >>>> >>> >>>>> >>>> >>> >>>>> warrants canceling the availability of the patch. If they are >>>> major >>>> >>> >>>>> architectural changes, then that makes more sense to me. >>>> >>> >>>>> >>>> >>> >>>>> Andy LoPresto >>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo >>>> >>> >>>>> pre...@apache.org> >>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com >>>> >>> ><mailto: >>>> >>> >>>>> alopresto.apa...@gmail.com> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D >>>> EF69 >>>> >>> >>>>> >>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <marka...@hotmail.com >>>> >>> <mailto:m >>>> >>> >>>>> arka...@hotmail.com><mailto:marka...@hotmail.com>> wrote: >>>> >>> >>>>> >>>> >>> >>>>> Personally, I am afraid that if we don't set a Fix Version on >>>> JIRA's, >>>> >>> >>> >>>> >>> >>> that >>>> >>> >>>>> >>>> >>> >>>>> some PR's will be lost >>>> >>> >>>>> or stalled. I rarely go to github and start looking through the >>>> PRs. >>>> >>> >>>>> Instead, I go to JIRA and look >>>> >>> >>>>> at what is assigned with a fixVersion of the next release. Then >>>> I'll >>>> >>> go >>>> >>> >>>>> and review JIRA's that are >>>> >>> >>>>> in a state of "Patch Available." Even then I often come across >>>> many >>>> >>> >>>>> PR's >>>> >>> >>>>> that have already been >>>> >>> >>>>> reviewed by one or more other committers and are awaiting >>>> updates. >>>> >>> >>>>> >>>> >>> >>>>> So I propose that we address this slightly differently. I believe >>>> >>> that >>>> >>> >>> >>>> >>> >>> we >>>> >>> >>>>> >>>> >>> >>>>> should assign a Fix Version to >>>> >>> >>>>> a JIRA whenever a PR is submitted. Then, whenever a committer >>>> >>> reviews a >>>> >>> >>>>> PR, he/she should be >>>> >>> >>>>> responsible for updating the JIRA. If the PR is merged then the >>>> JIRA >>>> >>> >>>>> should be resolved as Fixed. >>>> >>> >>>>> But if the PR is not merged because some changes are needed, the >>>> >>> >>> >>>> >>> >>> reviewer >>>> >>> >>>>> >>>> >>> >>>>> should then go back to >>>> >>> >>>>> the JIRA and click 'Cancel Patch'. We are typically very good >>>> about >>>> >>> >>>>> resolving as fixed once a PR is >>>> >>> >>>>> merged, but we don't typically cancel the patch otherwise. >>>> >>> >>>>> >>>> >>> >>>>> If we followed this workflow, then a Release Manager (or anyone >>>> else) >>>> >>> >>> >>>> >>> >>> can >>>> >>> >>>>> >>>> >>> >>>>> easily see which tickets >>>> >>> >>>>> need to be reviewed before a release happens and which ones can >>>> be >>>> >>> >>> >>>> >>> >>> pushed >>>> >>> >>>>> >>>> >>> >>>>> out because they >>>> >>> >>>>> are not ready (even if a PR has been posted). It also makes it >>>> much >>>> >>> >>> >>>> >>> >>> easier >>>> >>> >>>>> >>>> >>> >>>>> for reviewers to quickly >>>> >>> >>>>> know which tickets are awaiting review. >>>> >>> >>>>> >>>> >>> >>>>> Thoughts? >>>> >>> >>>>> >>>> >>> >>>>> -Mark >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> On Feb 23, 2017, at 3:37 AM, Andy LoPresto < >>>> >>> alopresto.apa...@gmail.com< >>>> >>> >>>>> mailto:alopresto.apa...@gmail.com><mailto: >>>> alopresto.apa...@gmail.com >>>> >>> >> >>>> >>> >>>>> wrote: >>>> >>> >>>>> >>>> >>> >>>>> As someone who has surely been guilty of optimistically setting >>>> fix >>>> >>> >>>>> versions and then not meeting them, I second Joe's point about it >>>> >>> >>> >>>> >>> >>> holding >>>> >>> >>>>> >>>> >>> >>>>> up releases. Better to get the PR out, reviewed, and merged >>>> *before* >>>> >>> >>>>> setting the fix version in my opinion. >>>> >>> >>>>> >>>> >>> >>>>> Andy LoPresto >>>> >>> >>>>> alopre...@apache.org<mailto:alopre...@apache.org><mailto:alo >>>> >>> >>>>> pre...@apache.org> >>>> >>> >>>>> alopresto.apa...@gmail.com<mailto:alopresto.apa...@gmail.com >>>> >>> ><mailto: >>>> >>> >>>>> alopresto.apa...@gmail.com> >>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D >>>> EF69 >>>> >>> >>>>> >>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.w...@gmail.com<mailto: >>>> joe >>>> >>> >>>>> .w...@gmail.com>> wrote: >>>> >>> >>>>> >>>> >>> >>>>> Peter, >>>> >>> >>>>> >>>> >>> >>>>> This is just my preference so discussion is certainly open. But >>>> the >>>> >>> >>>>> way I see it we should not set the fix version on JIRAs unless >>>> they >>>> >>> >>>>> really should block a release without resolution or if due to >>>> some >>>> >>> >>>>> roadmap/planning/discussion it is a new feature/improvement that >>>> is >>>> >>> >>>>> tied to a release. Otherwise, for the many things which pop up >>>> >>> >>>>> throughout a given release cycle they should be avoided. That >>>> is to >>>> >>> >>>>> say the majority of the time we'd avoid fix versions until the >>>> act of >>>> >>> >>>>> merging a contribution which also means it has been reviewed. >>>> >>> >>>>> >>>> >>> >>>>> From the release management point of view: >>>> >>> >>>>> This approach helps greatly as until now it is has been really >>>> >>> >>>>> difficult and time consuming to pull together/close down a >>>> release as >>>> >>> >>>>> pretty much anyone can set these fix versions and make it appear >>>> as >>>> >>> >>>>> though the release is not ready when in reality it is perfectly >>>> >>> >>>>> releasable as-is but might miss out on some contribs that someone >>>> >>> >>>>> would like to see in the release but has as of yet not gotten >>>> the PR >>>> >>> >>>>> and/or review traction necessary. >>>> >>> >>>>> >>>> >>> >>>>> From the contributor point of view: >>>> >>> >>>>> If someone makes a contribution they obviously want that code to >>>> end >>>> >>> >>>>> up in a release. But being an RTC community we need and want >>>> peer >>>> >>> >>>>> review before the code is submitted. Some contributions are >>>> frankly >>>> >>> >>>>> hard to get peer review on or simply take time for someone to >>>> >>> >>>>> volunteer to do. PRs which are difficult to test, lack testing, >>>> are >>>> >>> >>>>> related to systems or environments which are not easily >>>> replicated, >>>> >>> >>>>> etc.. are inherently harder to get peer review for. Also, the >>>> >>> >>>>> community has grown quite rapidly and sometimes the hygiene of a >>>> >>> given >>>> >>> >>>>> PR isn't great. So our 'patch available' and 'open PR' count >>>> ticks >>>> >>> >>>>> up. We need reviews/feedback as much as we need contributions >>>> so it >>>> >>> >>>>> is important for folks that want those contributions in to build >>>> >>> >>>>> meritocracy as well in reviewing others contributions. This >>>> helps >>>> >>> >>>>> build a network of contributors/reviewers and improves the >>>> timeliness >>>> >>> >>>>> of reviews. Long story short here is that because at times PRs >>>> can >>>> >>> >>>>> sit too long sometimes people put a fix version on the JIRA so it >>>> >>> acts >>>> >>> >>>>> as a sort of 'gating function' on the release. This I am saying >>>> is >>>> >>> >>>>> the practice that should not occur (given the thoughts above). >>>> We >>>> >>> >>>>> should instead take the issue of how to more effectively >>>> >>> >>>>> triage/review/provide feedback/and manage expectations for >>>> >>> >>>>> contributions so contributors don't feel like their stuff will >>>> just >>>> >>> >>>>> sit forever. >>>> >>> >>>>> >>>> >>> >>>>> Does that make sense and seem fair? >>>> >>> >>>>> >>>> >>> >>>>> Thanks >>>> >>> >>>>> Joe >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>>> On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) < >>>> >>> >>> >>>> >>> >>> pwi...@micron.com >>>> >>> >>>>> >>>> >>> >>>>> <mailto:pwi...@micron.com>> wrote: >>>> >>> >>>>> Just for clarification, "We really need to avoid the practice of >>>> >>> >>>>> setting >>>> >>> >>>>> fix versions without traction", would mean don't set a version >>>> number >>>> >>> >>> >>>> >>> >>> until >>>> >>> >>>>> >>>> >>> >>>>> after we've submitted a PR? Until after the PR has been closed? >>>> >>> Other? >>>> >>> >>>>> >>>> >>> >>>>> Thanks, >>>> >>> >>>>> Peter >>>> >>> >>>>> >>>> >>> >>>>> -----Original Message----- >>>> >>> >>>>> From: Joe Witt [mailto:joe.w...@gmail.com] >>>> >>> >>>>> Sent: Wednesday, February 22, 2017 12:55 PM >>>> >>> >>>>> To: dev@nifi.apache.org<mailto:dev@nifi.apache.org> >>>> >>> >>>>> Subject: Closing in on a NiFi 1.2.0 release? >>>> >>> >>>>> >>>> >>> >>>>> team, >>>> >>> >>>>> >>>> >>> >>>>> On the users lists we had an ask of when we are planning to cut a >>>> >>> >>>>> 1.2.0 release. And someone else asked me recently off-list. >>>> >>> >>>>> >>>> >>> >>>>> There are 45 open JIRAs tagged to it as of now. >>>> >>> >>>>> >>>> >>> >>>>> https://issues.apache.org/jira/issues/?jql=project%20% >>>> >>> >>>>> >>>> 3D%20NIFI%20AND%20fixVersion%20%3D%201.2.0%20AND%20resolution%20%3D% >>>> >>> >>>>> 20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC >>>> >>> >>>>> >>>> >>> >>>>> I'd be favorable to going through and seeing if we can start the >>>> >>> >>>>> motions >>>> >>> >>>>> for a 1.2.0 release and which are ones we can wait for and which >>>> we >>>> >>> >>> >>>> >>> >>> should >>>> >>> >>>>> >>>> >>> >>>>> have in 1.2.0 for sure. >>>> >>> >>>>> >>>> >>> >>>>> Is there any reason folks can think of to hold off on a 1.2.0 >>>> >>> release? >>>> >>> >>>>> >>>> >>> >>>>> A non trivial number of the JIRAs are for things which have or >>>> do not >>>> >>> >>> >>>> >>> >>> have >>>> >>> >>>>> >>>> >>> >>>>> PRs but have no review traction. We really need to avoid the >>>> >>> practice >>>> >>> >>> >>>> >>> >>> of >>>> >>> >>>>> >>>> >>> >>>>> setting fix versions without traction on this as otherwise it >>>> holds >>>> >>> up >>>> >>> >>> >>>> >>> >>> the >>>> >>> >>>>> >>>> >>> >>>>> releases. >>>> >>> >>>>> >>>> >>> >>>>> Thanks >>>> >>> >>>>> Joe >>>> >>> >>>>> >>>> >>> >>>>> >>>> >>> >>>> >>>> >>> >>>> -- >>>> >>> >>>> I know what it is to be in need, and I know what it is to have >>>> plenty. >>>> >>> >>>> I >>>> >>> >>>> have learned the secret of being content in any and every >>>> situation, >>>> >>> >>>> whether well fed or hungry, whether living in plenty or in want. >>>> I >>>> >>> can >>>> >>> >>> >>>> >>> >>> do >>>> >>> >>>> >>>> >>> >>>> all this through him who gives me strength. *-Philippians >>>> 4:12-13* >>>> >>> > >>>> >>> > >>>> >>> >>>> >>> -- >>> Sent from Gmail Mobile
