Mailing-List: contact dev-help@nifi.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@nifi.apache.org
MIME-Version: 1.0
In-Reply-To: <CALJK9a60+SDgRdWFYr3hEPAPFn_Ga24uxx1_aQ6C-BOqd9x3-Q@mail.gmail.com>
References: <CALJK9a6zQwwkz1JKXEpHs3zK8oc6NqnjjzkVaHMhfyZVSTJsJg@mail.gmail.com>
 <764a5da7ca1242c1a2a38d54e212c814@bowex17e.micron.com> <CALJK9a4t=DWA3nmfRLzrOJpMnmtGPyudEU8pHz7G-poxXCEYpw@mail.gmail.com>
 <166C4EDD-B85D-4C63-9A95-443AA58F1AF3@gmail.com> <DM5PR15MB12288BC4F7B586B8B78C1F59CE520@DM5PR15MB1228.namprd15.prod.outlook.com>
 <283F87A9-46F5-48CF-879E-7B228977772A@apache.org> <DM5PR15MB1228132438478F9968D74EC8CE520@DM5PR15MB1228.namprd15.prod.outlook.com>
 <BDD98297-D9D9-4EC4-8A74-295F6CD27488@apache.org> <DM5PR15MB12286DFDFCA431072E44A04DCE2B0@DM5PR15MB1228.namprd15.prod.outlook.com>
 <CAC8FukXXMD8=rejaWjF3aHOEhxe7eLD8f_TY9g_2PL_o=HmWCw@mail.gmail.com>
 <CALo_M19rnEv5dJKk==SzTS4b==i3HxG6YG8VEcrpPV-68efxMA@mail.gmail.com>
 <CAGdHs4o6V9Ydu6E8q=wrYZA=4smDfjyq=E9krjcX2n16dt1PHQ@mail.gmail.com>
 <58C05EDB.6090804@windofkeltia.com> <CALo_M193USDPvrU=aL6uaNk=JwUSUtGvf0u2z7+iPmT-4PRp4g@mail.gmail.com>
 <CAGdHs4rP8-Pk1F7uTWzi_e6cFUaAwVPBpFPsSgsOjCS1xiy7dQ@mail.gmail.com>
 <CALo_M1_+MWYoF2Dg7jCLKC=m303PevkPGFGCYyYvjLvc5rCw9g@mail.gmail.com>
 <CALJK9a6Tc4Zx+8j6yFM5VvHk8-QynWdrv+xC2kbeiWZ3LHkqVA@mail.gmail.com>
 <CALo_M1-CgdDYVh-nHZ_+OpCUPxRT7nhoQ7nC4p+1NSxY-P--dQ@mail.gmail.com> <CALJK9a60+SDgRdWFYr3hEPAPFn_Ga24uxx1_aQ6C-BOqd9x3-Q@mail.gmail.com>
From: Joe Witt <joe.witt@gmail.com>
Date: Tue, 28 Mar 2017 09:45:10 -0400
Message-ID: <CALJK9a6Btj8HG1GZBVCCkYmgKn7W3uwEg2fGOh+48983GQ3x1g@mail.gmail.com>
Subject: Re: Closing in on a NiFi 1.2.0 release?
To: dev@nifi.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
archived-at: Tue, 28 Mar 2017 13:45:20 -0000

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.witt@gmail.com> wrote:
> Sweet!  I'll take that deal all day.  Thanks Bryan!
>
> On Wed, Mar 22, 2017 at 8:26 PM, Bryan Bende <bbende@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 tomorro=
w.
>> 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.witt@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 <bbende@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 Mave=
n
>>> > 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=3DfixVersion%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 <jvwing@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 <bbende@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 JIR=
As
>>> >>> tagged for that release and try to figure out which ones can be mov=
ed
>>> >>> to a future release, and which ones the community is actually worki=
ng
>>> >>> 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 do=
ne
>>> >>> and figure that it can just be moved to next release, so I just wan=
ted
>>> >>> to mention that it is very close to being ready was still hoping fo=
r
>>> >>> 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 w=
ork
>>> >>> 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 f=
or
>>> >>> NiFi could also run against old NARs that don't have the new entrie=
s,
>>> >>> you just see everything as being "unversioned" and can't actually m=
ake
>>> >>> use of the new capabilities. We'll always have to be able to run ol=
der
>>> >>> 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 plugi=
n,
>>> >>> 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 <russ@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 ha=
rd
>>> 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 i=
s
>>> the
>>> >>> >> question more about the strategy for 1.2.0?
>>> >>> >>
>>> >>> >>
>>> >>> >> Thanks,
>>> >>> >>
>>> >>> >> James
>>> >>> >>
>>> >>> >> On Wed, Mar 8, 2017 at 9:06 AM, Bryan Bende <bbende@gmail.com>
>>> wrote:
>>> >>> >>
>>> >>> >>> Just wanted to mention that one of the JIRAs tagged for 1.2.0 i=
s
>>> >>> >>> NIFI-3380 "support multiple versions of the same component" [1]=
 and
>>> >>> >>> I've been working with Matt Gilman on this [2]. The functionali=
ty
>>> is
>>> >>> >>> very close to being done and I think we should get this into th=
e
>>> 1.2.0
>>> >>> >>> release.
>>> >>> >>>
>>> >>> >>> In order to fully leverage the versioned components we will nee=
d 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-boar=
d
>>> with
>>> >>> >>> this plan then I can advise when we are ready to release the ne=
w
>>> >>> >>> 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 <jgresock@gmail.com=
>
>>> >>> wrote:
>>> >>> >>>>
>>> >>> >>>> This is good discussion that should continue, but what about t=
he
>>> >>> >>>> 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 <markap14@hotmail.c=
om>
>>> >>> 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 id=
eal.
>>> >>> >>>>> Though
>>> >>> >>>>> we could certainly have a process
>>> >>> >>>>> by which we change the status to "In Progress" after cancelin=
g
>>> the
>>> >>> >>>
>>> >>> >>> patch.
>>> >>> >>>>>
>>> >>> >>>>> I guess where my viewpoint differs from yours is in the meani=
ng
>>> of
>>> >>> "In
>>> >>> >>>>> Review." Let's say that you submit a
>>> >>> >>>>> patch for a JIRA. I then review it and find that it needs som=
e
>>> 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, an=
d
>>> 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 <alopresto@apache.=
org
>>> >>> >>>
>>> >>> >>> <mailto:a
>>> >>> >>>>>
>>> >>> >>>>> lopresto@apache.org>> wrote:
>>> >>> >>>>>
>>> >>> >>>>> Mark,
>>> >>> >>>>>
>>> >>> >>>>> Your understanding of =E2=80=9CPatch Available=E2=80=9D certa=
inly makes sense
>>> and it
>>> >>> >>>>> explains why you approach the process the way you do. I have =
a
>>> >>> slightly
>>> >>> >>>>> different personal understanding of =E2=80=9CPatch Available=
=E2=80=9D =E2=80=94 I read
>>> it to
>>> >>> >>>
>>> >>> >>> mean
>>> >>> >>>>>
>>> >>> >>>>> =E2=80=9Cthe person responsible for this Jira has contributed=
 code they
>>> feel
>>> >>> >>>
>>> >>> >>> solves
>>> >>> >>>>>
>>> >>> >>>>> the issue.=E2=80=9D A review will (hopefully) determine if th=
at
>>> assertion is
>>> >>> >>>>> correct and complete. I think we kind of agree on "my viewpoi=
nt
>>> is
>>> >>> >>>
>>> >>> >>> simply
>>> >>> >>>>>
>>> >>> >>>>> that "Patch Available" means "Awaiting Review" or "In Review.=
=E2=80=9D=E2=80=9D
>>> but I
>>> >>> >>>
>>> >>> >>> see
>>> >>> >>>>>
>>> >>> >>>>> =E2=80=9CIn Review=E2=80=9D as a potentially iterative proces=
s =E2=80=94 it could be on
>>> the
>>> >>> >>>
>>> >>> >>> second
>>> >>> >>>>>
>>> >>> >>>>> pass of the contributor responding to comments, but it=E2=80=
=99s still
>>> =E2=80=9CIn
>>> >>> >>>
>>> >>> >>> Review=E2=80=9D
>>> >>> >>>>>
>>> >>> >>>>> in my eyes. I don=E2=80=99t know that the granularity of Jira=
 supports
>>> the
>>> >>> >>>
>>> >>> >>> specific
>>> >>> >>>>>
>>> >>> >>>>> workflow states of =E2=80=9Cbeen reviewed once but not comple=
te/accepted
>>> >>> yet=E2=80=9D.
>>> >>> >>>>>
>>> >>> >>>>> What state does =E2=80=9CCancel Patch=E2=80=9D result in? If =
it just reverts to
>>> >>> =E2=80=9COpen=E2=80=9D,
>>> >>> >>>
>>> >>> >>> I
>>> >>> >>>>>
>>> >>> >>>>> don=E2=80=99t see the value because that obfuscates the diffe=
rence
>>> between a
>>> >>> >>>
>>> >>> >>> Jira
>>> >>> >>>>>
>>> >>> >>>>> that hasn=E2=80=99t even been touched and one that has 90% of=
 the code
>>> done.
>>> >>> I
>>> >>> >>>>> agree we should make the RM=E2=80=99s job easier, but I also =
think it
>>> doesn=E2=80=99t
>>> >>> >>>
>>> >>> >>> help
>>> >>> >>>>>
>>> >>> >>>>> the visibility for reviewers to see a Jira marked as =E2=80=
=9Copen=E2=80=9D 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=E2=80=99=
m glad we=E2=80=99re
>>> >>> >>>
>>> >>> >>> talking
>>> >>> >>>>>
>>> >>> >>>>> about it.
>>> >>> >>>>>
>>> >>> >>>>> Andy LoPresto
>>> >>> >>>>> alopresto@apache.org<mailto:alopresto@apache.org>
>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com>
>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7=
D
>>> EF69
>>> >>> >>>>>
>>> >>> >>>>> On Feb 24, 2017, at 1:07 PM, Mark Payne <markap14@hotmail.com
>>> >>> <mailto:m
>>> >>> >>>>> arkap14@hotmail.com>> wrote:
>>> >>> >>>>>
>>> >>> >>>>> Andy,
>>> >>> >>>>>
>>> >>> >>>>> If the reviewer is looking for clarification, then it may mak=
e
>>> 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 t=
o
>>> "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 shoul=
d
>>> Cancel
>>> >>> >>>>> Patch.
>>> >>> >>>>>
>>> >>> >>>>> Do you or others have differing views on the meaning of "Patc=
h
>>> >>> >>>
>>> >>> >>> Available"?
>>> >>> >>>>>
>>> >>> >>>>> Thanks
>>> >>> >>>>> -Mark
>>> >>> >>>>>
>>> >>> >>>>>
>>> >>> >>>>> On Feb 24, 2017, at 3:27 PM, Andy LoPresto <alopresto@apache.=
org
>>> >>> >>>
>>> >>> >>> <mailto:a
>>> >>> >>>>>
>>> >>> >>>>> lopresto@apache.org><mailto:alopresto@apache.org>> wrote:
>>> >>> >>>>>
>>> >>> >>>>> Mark,
>>> >>> >>>>>
>>> >>> >>>>> I like your point about updating the Jira with the Fix Versio=
n
>>> at the
>>> >>> >>>
>>> >>> >>> time
>>> >>> >>>>>
>>> >>> >>>>> the PR review begins (or when the PR is submitted, if the
>>> contributor
>>> >>> >>>>> is
>>> >>> >>>>> aware of this process). I think it=E2=80=99s better than wait=
ing 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=E2=80=99t know if I am on the sam=
e page as
>>> you
>>> >>> for
>>> >>> >>>>> =E2=80=9CCancel Patch=E2=80=9D if the PR needs changes; somet=
imes these are minor
>>> >>> fixes
>>> >>> >>>
>>> >>> >>> or
>>> >>> >>>>>
>>> >>> >>>>> just looking for clarification from the contributor, and I do=
n=E2=80=99t
>>> >>> think
>>> >>> >>>
>>> >>> >>> that
>>> >>> >>>>>
>>> >>> >>>>> warrants canceling the availability of the patch. If they are
>>> major
>>> >>> >>>>> architectural changes, then that makes more sense to me.
>>> >>> >>>>>
>>> >>> >>>>> Andy LoPresto
>>> >>> >>>>> alopresto@apache.org<mailto:alopresto@apache.org><mailto:alo
>>> >>> >>>>> presto@apache.org>
>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com
>>> >>> ><mailto:
>>> >>> >>>>> alopresto.apache@gmail.com>
>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7=
D
>>> EF69
>>> >>> >>>>>
>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <markap14@hotmail.co=
m
>>> >>> <mailto:m
>>> >>> >>>>> arkap14@hotmail.com><mailto:markap14@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 t=
he
>>> PRs.
>>> >>> >>>>> Instead, I go to JIRA and look
>>> >>> >>>>> at what is assigned with a fixVersion of the next release. Th=
en
>>> I'll
>>> >>> go
>>> >>> >>>>> and review JIRA's that are
>>> >>> >>>>> in a state of "Patch Available." Even then I often come acros=
s
>>> 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 bel=
ieve
>>> >>> 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 t=
he
>>> 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 anyo=
ne
>>> else)
>>> >>> >>>
>>> >>> >>> can
>>> >>> >>>>>
>>> >>> >>>>> easily see which tickets
>>> >>> >>>>> need to be reviewed before a release happens and which ones c=
an
>>> be
>>> >>> >>>
>>> >>> >>> pushed
>>> >>> >>>>>
>>> >>> >>>>> out because they
>>> >>> >>>>> are not ready (even if a PR has been posted). It also makes i=
t
>>> 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.apache@gmail.com<
>>> >>> >>>>> mailto:alopresto.apache@gmail.com><mailto:
>>> alopresto.apache@gmail.com
>>> >>> >>
>>> >>> >>>>> wrote:
>>> >>> >>>>>
>>> >>> >>>>> As someone who has surely been guilty of optimistically setti=
ng
>>> fix
>>> >>> >>>>> versions and then not meeting them, I second Joe's point abou=
t it
>>> >>> >>>
>>> >>> >>> holding
>>> >>> >>>>>
>>> >>> >>>>> up releases. Better to get the PR out, reviewed, and merged
>>> *before*
>>> >>> >>>>> setting the fix version in my opinion.
>>> >>> >>>>>
>>> >>> >>>>> Andy LoPresto
>>> >>> >>>>> alopresto@apache.org<mailto:alopresto@apache.org><mailto:alo
>>> >>> >>>>> presto@apache.org>
>>> >>> >>>>> alopresto.apache@gmail.com<mailto:alopresto.apache@gmail.com
>>> >>> ><mailto:
>>> >>> >>>>> alopresto.apache@gmail.com>
>>> >>> >>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7=
D
>>> EF69
>>> >>> >>>>>
>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.witt@gmail.com<mailt=
o:
>>> joe
>>> >>> >>>>> .witt@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 unles=
s
>>> they
>>> >>> >>>>> really should block a release without resolution or if due to
>>> some
>>> >>> >>>>> roadmap/planning/discussion it is a new feature/improvement t=
hat
>>> is
>>> >>> >>>>> tied to a release.  Otherwise, for the many things which pop =
up
>>> >>> >>>>> throughout a given release cycle they should be avoided.  Tha=
t
>>> is to
>>> >>> >>>>> say the majority of the time we'd avoid fix versions until th=
e
>>> 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 reall=
y
>>> >>> >>>>> difficult and time consuming to pull together/close down a
>>> release as
>>> >>> >>>>> pretty much anyone can set these fix versions and make it app=
ear
>>> as
>>> >>> >>>>> though the release is not ready when in reality it is perfect=
ly
>>> >>> >>>>> releasable as-is but might miss out on some contribs that som=
eone
>>> >>> >>>>> 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 testi=
ng,
>>> are
>>> >>> >>>>> related to systems or environments which are not easily
>>> replicated,
>>> >>> >>>>> etc.. are inherently harder to get peer review for.  Also, th=
e
>>> >>> >>>>> community has grown quite rapidly and sometimes the hygiene o=
f 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 contribution=
s
>>> so it
>>> >>> >>>>> is important for folks that want those contributions in to bu=
ild
>>> >>> >>>>> 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 P=
Rs
>>> can
>>> >>> >>>>> sit too long sometimes people put a fix version on the JIRA s=
o it
>>> >>> acts
>>> >>> >>>>> as a sort of 'gating function' on the release.  This I am say=
ing
>>> 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 wil=
l
>>> just
>>> >>> >>>>> sit forever.
>>> >>> >>>>>
>>> >>> >>>>> Does that make sense and seem fair?
>>> >>> >>>>>
>>> >>> >>>>> Thanks
>>> >>> >>>>> Joe
>>> >>> >>>>>
>>> >>> >>>>>
>>> >>> >>>>>
>>> >>> >>>>> On Wed, Feb 22, 2017 at 2:39 PM, Peter Wicks (pwicks) <
>>> >>> >>>
>>> >>> >>> pwicks@micron.com
>>> >>> >>>>>
>>> >>> >>>>> <mailto:pwicks@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 versio=
n
>>> number
>>> >>> >>>
>>> >>> >>> until
>>> >>> >>>>>
>>> >>> >>>>> after we've submitted a PR? Until after the PR has been close=
d?
>>> >>> Other?
>>> >>> >>>>>
>>> >>> >>>>> Thanks,
>>> >>> >>>>> Peter
>>> >>> >>>>>
>>> >>> >>>>> -----Original Message-----
>>> >>> >>>>> From: Joe Witt [mailto:joe.witt@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 c=
ut 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=3Dproject%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 wh=
ich
>>> 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 o=
r
>>> 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 wan=
t.
>>> I
>>> >>> can
>>> >>> >>>
>>> >>> >>> do
>>> >>> >>>>
>>> >>> >>>> all this through him who gives me strength.    *-Philippians
>>> 4:12-13*
>>> >>> >
>>> >>> >
>>> >>>
>>>
>> --
>> Sent from Gmail Mobile