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 >
