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:[email protected]> >> >>> >>>>> 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:[email protected] >> >>> ><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:[email protected] >> >>> ><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
