nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: Closing in on a NiFi 1.2.0 release?
Date Tue, 11 Apr 2017 19:20:19 GMT
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 <trkurc@gmail.com> 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 <joe.witt@gmail.com> 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 <joe.witt@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.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
>> 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.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
>> 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 <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
>> 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 <
>> 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
>> 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 <bbende@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 <
>> jgresock@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 <
>> markap14@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 <
>> alopresto@apache.org
>> >>>> >>> >>>
>> >>>> >>> >>> <mailto:a
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> lopresto@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
>> >>>> >>> >>>>> 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
>> 2F7D
>> >>>> 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
>> 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 <
>> 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
>> 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
>> >>>> >>> >>>>> 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
>> 2F7D
>> >>>> EF69
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 24, 2017, at 12:08 PM, Mark Payne <
>> markap14@hotmail.com
>> >>>> >>> <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
>> 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.apache@gmail.com<
>> >>>> >>> >>>>> mailto:alopresto.apache@gmail.com><mailto:
>> >>>> alopresto.apache@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
>> >>>> >>> >>>>> 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
>> 2F7D
>> >>>> EF69
>> >>>> >>> >>>>>
>> >>>> >>> >>>>> On Feb 22, 2017, at 19:39, Joe Witt <joe.witt@gmail.com
>> <mailto:
>> >>>> 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
>> 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) <
>> >>>> >>> >>>
>> >>>> >>> >>> 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
>> 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.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
>> 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
>>

Mime
View raw message