Sean, how about yetus? Is this something yetus can do with the patch testing in an automated way? On Apr 4, 2016 1:14 PM, "Sean Busbey" <[email protected]> wrote:
> You're correct, a github PR only targets a single branch and Travis-CI > only checks how the PR does at its own commit hash (that is, it > doesn't even check what the target branch would look like post-merge). > > On Mon, Apr 4, 2016 at 12:05 PM, Matt Gilman <[email protected]> > wrote: > > To my knowledge, when you open a PR in GitHub it only allows the > > contributor to select a single branch. The reviewer would need to check > the > > compatibility if that contribution needs to be applied to both. Depending > > on the contribution, a separate PR may be required as the codebases > > diverge. In practice though, most of the work on master (1.x) will focus > on > > the framework which is where diverging is most likely to occur. > > Consequently, framework bug fixes are the most likely place where we may > > need separate PRs. > > > > On Mon, Apr 4, 2016 at 12:46 PM, Tony Kurc <[email protected]> wrote: > > > >> Is travis ci / githib able to give immediate feedback if a PR doesn't > merge > >> into both? > >> > >> On Mon, Apr 4, 2016 at 12:33 PM, Matt Gilman <[email protected]> > >> wrote: > >> > >> > All, > >> > > >> > I have completed the branching discussed last week. > >> > > >> > - master contains the current 1.x baseline - Future 1.x releases will > >> start > >> > from here > >> > - 0.x contains the 0.x baseline - Future 0.x releases will start from > >> here > >> > > >> > Going forward all PRs will need to be merged the either or both > branches > >> as > >> > appropriate to ensure it's included in subsequent releases. I will be > >> > updating the quick start and contributor guide to describe the > >> distinction > >> > between the two branches. > >> > > >> > Thanks! > >> > > >> > Matt > >> > > >> > On Thu, Mar 31, 2016 at 4:35 PM, Matt Gilman <[email protected] > > > >> > wrote: > >> > > >> > > The majority consensus is to have master point to our 1.x baseline > >> going > >> > > forward. Unless there are any strong objections I will set > everything > >> up > >> > on > >> > > Monday (4/4) morning. > >> > > > >> > > - Create a 0.x branch for all future 0.x releases based on the > current > >> > > state of master. > >> > > - Apply all 1.x commits from the temporary 1.x branch to master. > >> > > - Delete the temporary 1.x branch. > >> > > - Update the quickstart page and contribution guide to detail the > >> > > distinction between the 0.x and master branches. > >> > > - Send another email to @dev once this has been completed. > >> > > > >> > > Reminder: Going forward once this has been completed all commits > will > >> > need > >> > > to be made to both branches as appropriate. > >> > > > >> > > Thanks! > >> > > > >> > > Matt > >> > > > >> > > On Tue, Mar 29, 2016 at 3:05 PM, Matt Gilman < > [email protected]> > >> > > wrote: > >> > > > >> > >> Matt, > >> > >> > >> > >> I agree that the PRs would need to be merged to both baselines at > >> > >> contribution time. If the contribution applies cleanly the reviewer > >> > could > >> > >> certainly handle the commit themselves. However, if additional code > >> > changes > >> > >> are required because the baselines have diverged, the contributor > >> would > >> > >> probably need to submit another PR. This additional effort should > only > >> > be > >> > >> necessary until we're able to perform the first 1.x release. > >> > >> > >> > >> Aldrin, > >> > >> > >> > >> I definitely understand your thoughts regarding (1) and (2). This > is > >> why > >> > >> I wanted to pose the options before just jumping into one approach > vs > >> > the > >> > >> other. I personally prefer the GitHub style PR process. I realize > this > >> > is > >> > >> more cumbersome but hopefully the number of conflicts should be > small > >> as > >> > >> folks are already starting to focus their efforts on the framework > for > >> > 1.x. > >> > >> > >> > >> Matt > >> > >> > >> > >> On Tue, Mar 29, 2016 at 10:55 AM, Aldrin Piri < > [email protected]> > >> > >> wrote: > >> > >> > >> > >>> I think I prefer option 2 considering, what may be the incorrect > >> > >>> assumption, that rebasing 1.x on 0.x / pushing into 1.x would be > >> > easier. > >> > >>> Based on outstanding PRs/Patches in conjunction with release > cadence > >> > >>> there > >> > >>> will be more 0.x releases planned. Until we reached the point > where > >> the > >> > >>> first 1.x release is in sight, I think (2) makes sense just from > >> > >>> minimizing > >> > >>> impedance where the majority of effort will occur (new/updated > >> > >>> extensions) > >> > >>> and then switching to (1) when we are scheduling 1.x as next > >> (exclusive > >> > >>> of > >> > >>> any patch builds). This seems to work out when I try to reason > about > >> > it, > >> > >>> but admittedly, am coming at this heavily from my own anecdotal > >> > >>> perspective > >> > >>> given my flow of reviewing. > >> > >>> > >> > >>> Matt, excellent points to consider. > >> > >>> > >> > >>> Do not want to go too much on a tangent from the current > >> conversation, > >> > >>> but > >> > >>> I think we need to harness automation as much as possible. Not > sure > >> > >>> Travis > >> > >>> can do this or do so easily (short of two PRs) and this may > arguably > >> > >>> shift > >> > >>> things in favor of patches and the model that the other ASF > projects > >> > >>> utilize with buildbot. Getting as much done asynchronously for > us is > >> > >>> obviously important but we also have to strive to avoid a contrib > >> > process > >> > >>> that is too cumbersome as well. > >> > >>> > >> > >>> On Tue, Mar 29, 2016 at 10:33 AM, Matt Burgess < > [email protected]> > >> > >>> wrote: > >> > >>> > >> > >>> > I like option 1 as well. > >> > >>> > > >> > >>> > In the case where a fix is to be put into both branches, will > the > >> > >>> developer > >> > >>> > be responsible for issuing 2 PRs / patches, one against each > >> branch? > >> > >>> This > >> > >>> > would help in the case that the PR/patch against 0.x won't merge > >> > >>> cleanly > >> > >>> > into master; however the reviewer(s) would need to make sure > there > >> > >>> were no > >> > >>> > breaking changes as a result of the manual merge to master. An > >> > >>> alternative > >> > >>> > is that the reviewer(s) do the forward-port, which I don't think > >> is a > >> > >>> good > >> > >>> > idea. However the reviewer would need to make sure the PR(s) are > >> > >>> against > >> > >>> > the correct branch. For example, all current PRs would need to > be > >> > >>> > "backported" to the new 0.x branch. > >> > >>> > > >> > >>> > Also, I would think the PRs/patches need to be merged at the > same > >> > time > >> > >>> (or > >> > >>> > soon), to avoid regressions (i.e. a bug fix going into 0.x but > >> > getting > >> > >>> > forgotten/missed for 1.x). > >> > >>> > > >> > >>> > Thoughts? Thanks, > >> > >>> > Matt > >> > >>> > > >> > >>> > On Tue, Mar 29, 2016 at 10:26 AM, Joe Witt <[email protected]> > >> > wrote: > >> > >>> > > >> > >>> > > I too prefer option 1 > >> > >>> > > > >> > >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <[email protected] > > > >> > >>> wrote: > >> > >>> > > > I agree with Tony on option 1. I think it makes sense for > >> > master > >> > >>> to > >> > >>> > be > >> > >>> > > > the most "advanced" branch. New features will then always > be > >> > >>> applied > >> > >>> > to > >> > >>> > > > master, and optionally to other branches for older version > >> > support > >> > >>> as > >> > >>> > > > applicable / desired. > >> > >>> > > > > >> > >>> > > > On Tue, Mar 29, 2016 at 10:16 AM Tony Kurc < > [email protected]> > >> > >>> wrote: > >> > >>> > > > > >> > >>> > > >> I like option 1 > >> > >>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" < > >> > [email protected]> > >> > >>> > > wrote: > >> > >>> > > >> > >> > >>> > > >> > Hello, > >> > >>> > > >> > > >> > >>> > > >> > With NiFi 0.6.0 officially released and our support > strategy > >> > >>> defined > >> > >>> > > [1], > >> > >>> > > >> > I'd like to revisit and propose some options for > supporting > >> > >>> both a > >> > >>> > 1.x > >> > >>> > > >> > branch and 0.x branch concurrently. We need an official > >> place > >> > >>> where > >> > >>> > > these > >> > >>> > > >> > efforts can be worked, contributed to, and collaborated > with > >> > the > >> > >>> > > >> community. > >> > >>> > > >> > I've already created a 1.x branch as a temporary place > for > >> > this > >> > >>> > > codebase > >> > >>> > > >> to > >> > >>> > > >> > live until we agree to an approach. > >> > >>> > > >> > > >> > >>> > > >> > Either option I'm proposing will require > >> > >>> PRs/contributions/patches > >> > >>> > to > >> > >>> > > be > >> > >>> > > >> > applied to both branches as applicable. This means that > the > >> > >>> > > contributor > >> > >>> > > >> or > >> > >>> > > >> > the reviewer will need to be able to apply the commits in > >> both > >> > >>> > places > >> > >>> > > if > >> > >>> > > >> > it's necessary. For instance, framework code has already > >> > started > >> > >>> > > >> diverging > >> > >>> > > >> > from the current master so any framework change may not > need > >> > to > >> > >>> be > >> > >>> > > >> applied > >> > >>> > > >> > to both if the changeset is not applicable to the 1.x > >> > baseline. > >> > >>> > > >> > > >> > >>> > > >> > The only question at the moment is what master will refer > >> to. > >> > >>> > > >> > > >> > >>> > > >> > 1) Create a branch for 0.x and allow master to become the > >> 1.x > >> > >>> > baseline > >> > >>> > > >> > going forward. Future 0.x releases will be performed from > >> the > >> > >>> 0.x > >> > >>> > > branch. > >> > >>> > > >> > 2) Continuing working on the 1.x branch as is. Allow > master > >> to > >> > >>> > > continue > >> > >>> > > >> to > >> > >>> > > >> > servicing 0.x releases. Once a 1.x release is made, > create > >> the > >> > >>> 0.x > >> > >>> > > branch > >> > >>> > > >> > and then allow master to service 1.x releases. > >> > >>> > > >> > > >> > >>> > > >> > In short, when do we want master to point to the 1.x > >> baseline? > >> > >>> When > >> > >>> > > >> should > >> > >>> > > >> > we create a branch where 0.x releases will be made from. > >> > >>> Regardless, > >> > >>> > > >> > contributions will need to be performed to both places as > >> > >>> > applicable. > >> > >>> > > >> > > >> > >>> > > >> > Thanks. > >> > >>> > > >> > > >> > >>> > > >> > Matt > >> > >>> > > >> > > >> > >>> > > >> > [1] > >> > >>> > > >> > > >> > >>> > > >> > > >> > >>> > > >> > >> > >>> > > > >> > >>> > > >> > >>> > >> > > >> > http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E > >> > >>> > > >> > > >> > >>> > > >> > On Sat, Feb 27, 2016 at 10:08 AM, Richard Miskin < > >> > >>> > > [email protected]> > >> > >>> > > >> > wrote: > >> > >>> > > >> > > >> > >>> > > >> > > I guess it will depend how much change is expected on > the > >> > >>> > > maintenance > >> > >>> > > >> > > branches, > >> > >>> > > >> > > but if you want every change in the maintenance branch > to > >> go > >> > >>> into > >> > >>> > > the > >> > >>> > > >> > > main-line branch then there is little difference from a > >> > >>> conflict > >> > >>> > > point > >> > >>> > > >> of > >> > >>> > > >> > > view > >> > >>> > > >> > > between a series of cherry-picks and a merge. > >> > >>> > > >> > > > >> > >>> > > >> > > Either way, it is just another approach to consider. > >> There’s > >> > >>> more > >> > >>> > > than > >> > >>> > > >> > one > >> > >>> > > >> > > way to do it, and I suspect there isn’t any solution > that > >> > >>> makes it > >> > >>> > > >> > trivial. > >> > >>> > > >> > > > >> > >>> > > >> > > Cheers, > >> > >>> > > >> > > Richard > >> > >>> > > >> > > > >> > >>> > > >> > > > >> > >>> > > >> > > > On 27 Feb 2016, at 14:43, Aldrin Piri < > >> > [email protected] > >> > >>> > > >> > >>> > > wrote: > >> > >>> > > >> > > > > >> > >>> > > >> > > > On board with Tony's points. I think the realities > of > >> > >>> merging > >> > >>> > in > >> > >>> > > >> > > practice > >> > >>> > > >> > > > when that "breaking point" of sorts occurs will make > the > >> > >>> > > complexity > >> > >>> > > >> and > >> > >>> > > >> > > > overhead quite difficult and maybe even more error > prone > >> > >>> than > >> > >>> > the > >> > >>> > > >> > cherry > >> > >>> > > >> > > > picking approach with some additional guidelines. > When > >> > the > >> > >>> > > codebase > >> > >>> > > >> > > > drastically changes, the merge conflicts could be > quite > >> > >>> severe > >> > >>> > and > >> > >>> > > >> > > without > >> > >>> > > >> > > > a good knowledge of each part of the codebase > involved > >> > >>> during > >> > >>> > that > >> > >>> > > >> > > process, > >> > >>> > > >> > > > a committer may introduce regressions. > >> > >>> > > >> > > > > >> > >>> > > >> > > > On Sat, Feb 27, 2016 at 7:58 AM, Tony Kurc < > >> > >>> [email protected]> > >> > >>> > > wrote: > >> > >>> > > >> > > > > >> > >>> > > >> > > >> the reason I like applying patches to both lines is > >> that > >> > >>> once > >> > >>> > > code > >> > >>> > > >> > > begins > >> > >>> > > >> > > >> to diverge, cleanly merging into one codebase can be > >> > >>> > impossible. > >> > >>> > > >> > having > >> > >>> > > >> > > >> good practices for managing patches and where they > >> apply > >> > is > >> > >>> > > >> paramount > >> > >>> > > >> > > for > >> > >>> > > >> > > >> success. > >> > >>> > > >> > > >> > >> > >>> > > >> > > >> I expect that divergence to happen with 1.x. I > wanted > >> to > >> > >>> get > >> > >>> > in a > >> > >>> > > >> > battle > >> > >>> > > >> > > >> rhythm of sorts of managing multiple lines, even if > the > >> > >>> patches > >> > >>> > > >> COULD > >> > >>> > > >> > be > >> > >>> > > >> > > >> applied to both in the manner you described. > >> > >>> > > >> > > >> > >> > >>> > > >> > > >> Joe W and I did a wee bit of scrambling to ensure > that > >> > >>> tickets > >> > >>> > > >> marked > >> > >>> > > >> > > for > >> > >>> > > >> > > >> 0.5.1 had the right patches in the support branch, > and > >> > some > >> > >>> > > didn't, > >> > >>> > > >> > so I > >> > >>> > > >> > > >> think "lesson learned". I do like in the apache > >> > >>> infrastructure > >> > >>> > > that > >> > >>> > > >> if > >> > >>> > > >> > > >> commits have the appropriate ticket in their commit > >> > >>> message, > >> > >>> > the > >> > >>> > > >> jira > >> > >>> > > >> > > will > >> > >>> > > >> > > >> have the list of commits and branches those commits > >> were > >> > >>> > applies > >> > >>> > > to. > >> > >>> > > >> > > >> However, I think we may need to revisit commit > message > >> > >>> > > "hygiene" if > >> > >>> > > >> > we > >> > >>> > > >> > > >> relied on this instead of more manual review. > >> > >>> > > >> > > >> > >> > >>> > > >> > > >> > >> > >>> > > >> > > >> > >> > >>> > > >> > > >> > >> > >>> > > >> > > >> > >> > >>> > > >> > > >> On Sat, Feb 27, 2016 at 4:45 AM, Richard Miskin < > >> > >>> > > >> [email protected] > >> > >>> > > >> > > > >> > >>> > > >> > > >> wrote: > >> > >>> > > >> > > >> > >> > >>> > > >> > > >>> Hi, > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >>> On a couple of work projects we found that the > >> approach > >> > of > >> > >>> > > >> > > cherry-picking > >> > >>> > > >> > > >>> commits can lead to an unnecessarily complicated > >> history > >> > >>> where > >> > >>> > > the > >> > >>> > > >> > same > >> > >>> > > >> > > >>> piece of work appears as multiple separate commits > on > >> > >>> > different > >> > >>> > > >> > > branches. > >> > >>> > > >> > > >>> This can then make it hard to be confident that a > bug > >> > fix > >> > >>> has > >> > >>> > > been > >> > >>> > > >> > > >> applied > >> > >>> > > >> > > >>> to all relevant branches. We found that it works > >> better > >> > >>> to aim > >> > >>> > > to > >> > >>> > > >> > > commit > >> > >>> > > >> > > >>> changes to the lowest applicable branch, and then > >> > >>> regularly > >> > >>> > > merge > >> > >>> > > >> > those > >> > >>> > > >> > > >>> branches to master. This approach is based on the > >> > git-flow > >> > >>> > > model ( > >> > >>> > > >> > > >>> > >> http://nvie.com/posts/a-successful-git-branching-model/ > >> > < > >> > >>> > > >> > > >>> > >> http://nvie.com/posts/a-successful-git-branching-model/ > >> > >>> >). > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >>> Looking at the repo there are already a few commits > >> that > >> > >>> are > >> > >>> > > >> > duplicated > >> > >>> > > >> > > >> on > >> > >>> > > >> > > >>> master and 0.5.1. Using the model I suggest they’d > >> only > >> > >>> occur > >> > >>> > on > >> > >>> > > >> > 0.5.1, > >> > >>> > > >> > > >> and > >> > >>> > > >> > > >>> then that branch would get merged to master. > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >>> Having the merge commits from the support branch to > >> > master > >> > >>> > > makes it > >> > >>> > > >> > > >>> explicit in the git history that all bug fixes (and > >> > >>> associated > >> > >>> > > >> tests) > >> > >>> > > >> > > >> have > >> > >>> > > >> > > >>> been pulled through to master. > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >>> Cheers, > >> > >>> > > >> > > >>> Richard > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >>>> On 26 Feb 2016, at 06:59, James Wing < > >> [email protected] > >> > > > >> > >>> > wrote: > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> Thanks, Joe, let me try rephrasing a few of those > and > >> > >>> see if > >> > >>> > > you > >> > >>> > > >> > > agree: > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> 1.) Commits merged to master today are destined > for > >> the > >> > >>> next > >> > >>> > > minor > >> > >>> > > >> > > >>> release, > >> > >>> > > >> > > >>>> currently 0.6.0, by default? > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> By default, commits to master will be released in > the > >> > >>> next > >> > >>> > > major > >> > >>> > > >> or > >> > >>> > > >> > > >> minor > >> > >>> > > >> > > >>>> release. No commits are included in > >> incremental/patch > >> > >>> > > releases by > >> > >>> > > >> > > >>> default. > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> 3.) How long will support/0.5.x be maintained? > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> support/0.5.x will be maintained until the first > of > >> the > >> > >>> > > following > >> > >>> > > >> > > >> events: > >> > >>> > > >> > > >>>> a.) 0.6.0 is released (next minor release in major > >> > >>> release > >> > >>> > > line) > >> > >>> > > >> > > >>>> b.) One year after 1.0.0 is released ("previous > major > >> > >>> release > >> > >>> > > >> lines > >> > >>> > > >> > up > >> > >>> > > >> > > >> to > >> > >>> > > >> > > >>>> one year since the last minor release (0.4.y, > 1.5.y) > >> in > >> > >>> that > >> > >>> > > >> line") > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> But additional support might be available by > special > >> > >>> request. > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> 4.) Where is compatibility-breaking code destined > >> for a > >> > >>> > future > >> > >>> > > >> major > >> > >>> > > >> > > >>>> release stored? Is it visible anywhere? > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> I suppose Jira tickets targeting the next major > >> release > >> > >>> > > >> > > >>> could/should/would > >> > >>> > > >> > > >>>> (do?) push branches. That seems weak in the face > of > >> a > >> > >>> > probable > >> > >>> > > >> > > >> stampede > >> > >>> > > >> > > >>>> towards the fire exit of a major release, but > it's a > >> > >>> start. > >> > >>> > > I'm > >> > >>> > > >> not > >> > >>> > > >> > > >>> aware > >> > >>> > > >> > > >>>> of any great solutions here, certainly not for an > >> > >>> open-source > >> > >>> > > >> > project. > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>> On Thu, Feb 25, 2016 at 4:56 PM, Joe Witt < > >> > >>> > [email protected]> > >> > >>> > > >> > wrote: > >> > >>> > > >> > > >>>> > >> > >>> > > >> > > >>>>> James, > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> These are great questions to frame and test the > >> model. > >> > >>> So > >> > >>> > > let's > >> > >>> > > >> > > >>>>> attempt to address them agains the model. > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> Here is the language for that model at this time: > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> - We support the newest major release line (0.x, > >> 1.x) > >> > >>> and > >> > >>> > any > >> > >>> > > >> > > previous > >> > >>> > > >> > > >>>>> major release lines up to one year since the last > >> > minor > >> > >>> > > release > >> > >>> > > >> > > >>>>> (0.4.y, 1.5.y) in that line > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> - When master has no releases we will backport > any > >> > >>> > appropriate > >> > >>> > > >> > > changes > >> > >>> > > >> > > >>>>> (fix, feature, enhancement) to the previous major > >> > >>> release > >> > >>> > line > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> - Any security or data loss related fixes should > be > >> > back > >> > >>> > > ported > >> > >>> > > >> to > >> > >>> > > >> > > all > >> > >>> > > >> > > >>>>> supported major release lines > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> - Fixes, improvements, features will be applied > to > >> the > >> > >>> next > >> > >>> > > >> release > >> > >>> > > >> > > >>>>> (minor or incremental) within a given major > release > >> > >>> line and > >> > >>> > > will > >> > >>> > > >> > > only > >> > >>> > > >> > > >>>>> be back ported on a case by case basis for fixes > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> - In order to consider a patch for back porting > to a > >> > >>> > previous > >> > >>> > > >> minor > >> > >>> > > >> > > >>>>> release line a request needs to be made to the > >> > >>> developer or > >> > >>> > > user > >> > >>> > > >> > > >>>>> mailing list with a successful discussion and a > >> > release > >> > >>> > > candidate > >> > >>> > > >> > > >>>>> produced' > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> So with those above let's review 1 through 5 in > >> turn. > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> 1.) Commits merged to master today are destined > for > >> > the > >> > >>> next > >> > >>> > > >> minor > >> > >>> > > >> > > >>>>> release, currently 0.6.0, by default? > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> Master is for whatever is the most leading edge > >> > release > >> > >>> line > >> > >>> > > >> > working > >> > >>> > > >> > > >>>>> toward the next release. At the time that a > minor > >> > >>> release > >> > >>> > > occurs > >> > >>> > > >> > > >>>>> against that release line then it branches off > into > >> a > >> > >>> > > >> support/x.y.* > >> > >>> > > >> > > >>>>> branch for any further efforts against it. > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> 2.) Is master always open for merging new code, > or > >> are > >> > >>> there > >> > >>> > > >> > > >>> restrictions > >> > >>> > > >> > > >>>>> before or after releases? > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> I believe master would be always open for new > code. > >> > >>> From > >> > >>> > some > >> > >>> > > >> > point > >> > >>> > > >> > > >>>>> at which a release is considered feature complete > >> then > >> > >>> > further > >> > >>> > > >> > > feature > >> > >>> > > >> > > >>>>> enhancements need to go on master as part of the > >> next > >> > >>> > release > >> > >>> > > >> > effort. > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> 3.) How long will support/0.5.x be maintained? > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> The most recent minor release line of a major > line > >> > will > >> > >>> be > >> > >>> > > >> > supported > >> > >>> > > >> > > >>>>> for up to one year from whenever it was released > >> where > >> > >>> > > support is > >> > >>> > > >> > for > >> > >>> > > >> > > >>>>> bug fixes for security or data loss related > items. > >> > >>> Releases > >> > >>> > > for > >> > >>> > > >> > > older > >> > >>> > > >> > > >>>>> minor lines should be considered on a case by > case > >> > >>> basis and > >> > >>> > > if > >> > >>> > > >> > > >>>>> requested. Otherwise the basic premise is the > train > >> > is > >> > >>> > moving > >> > >>> > > >> > > >>>>> forward. > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> 4.) Where is compatibility-breaking code destined > >> for > >> > a > >> > >>> > future > >> > >>> > > >> > major > >> > >>> > > >> > > >>>>> release stored? Is it visible anywhere? > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> It must be visible. It should be placed into a > >> branch > >> > >>> until > >> > >>> > > such > >> > >>> > > >> > > >>>>> time that it is ready to become the new master. > >> That > >> > >>> time > >> > >>> > > would > >> > >>> > > >> be > >> > >>> > > >> > > >>>>> when the next release will be for that line. > When I > >> > >>> think > >> > >>> > > about > >> > >>> > > >> > this > >> > >>> > > >> > > >>>>> against the stated model we could probably tweak > the > >> > >>> wording > >> > >>> > > to > >> > >>> > > >> > > better > >> > >>> > > >> > > >>>>> articulate that. I think it was what was meant > with > >> > >>> 'when > >> > >>> > > master > >> > >>> > > >> > has > >> > >>> > > >> > > >>>>> no releases we will backport...' but that is > >> unclear. > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> 5.) A critical data/security bug found after 1.0 > >> would > >> > >>> > > eligible > >> > >>> > > >> to > >> > >>> > > >> > be > >> > >>> > > >> > > >>>>> backported only to the last minor release in the > 0.x > >> > >>> line, > >> > >>> > or > >> > >>> > > to > >> > >>> > > >> > all > >> > >>> > > >> > > >>> minor > >> > >>> > > >> > > >>>>> releases in the 0.x line? > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> Only to the most recent minor release of any > still > >> > >>> supported > >> > >>> > > >> major > >> > >>> > > >> > > >>>>> line. However, the catch of 'case by case' > >> > >>> determination > >> > >>> > for > >> > >>> > > >> older > >> > >>> > > >> > > >>>>> minor lines is still in play. Basically if > someone > >> > >>> requests > >> > >>> > > it > >> > >>> > > >> and > >> > >>> > > >> > > >>>>> can get enough momentum for it then it should be > no > >> > >>> problem > >> > >>> > to > >> > >>> > > >> > > produce > >> > >>> > > >> > > >>>>> such a release. > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> Thanks > >> > >>> > > >> > > >>>>> Joe > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>>>> On Thu, Feb 25, 2016 at 3:15 PM, James Wing < > >> > >>> > [email protected] > >> > >>> > > > > >> > >>> > > >> > > wrote: > >> > >>> > > >> > > >>>>>> I have some rhetorical questions for discussion > of > >> > the > >> > >>> > > branching > >> > >>> > > >> > > >> model: > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> 1.) Commits merged to master today are destined > for > >> > the > >> > >>> > next > >> > >>> > > >> minor > >> > >>> > > >> > > >>>>> release, > >> > >>> > > >> > > >>>>>> currently 0.6.0, by default? > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> 2.) Is master always open for merging new code, > or > >> > are > >> > >>> > there > >> > >>> > > >> > > >>> restrictions > >> > >>> > > >> > > >>>>>> before or after releases? > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> 3.) How long will support/0.5.x be maintained? > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> 4.) Where is compatibility-breaking code > destined > >> > for a > >> > >>> > > future > >> > >>> > > >> > major > >> > >>> > > >> > > >>>>>> release stored? Is it visible anywhere? > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> 5.) A critical data/security bug found after 1.0 > >> > would > >> > >>> > > eligible > >> > >>> > > >> to > >> > >>> > > >> > > be > >> > >>> > > >> > > >>>>>> backported only to the last minor release in the > >> 0.x > >> > >>> line, > >> > >>> > > or to > >> > >>> > > >> > all > >> > >>> > > >> > > >>>>> minor > >> > >>> > > >> > > >>>>>> releases in the 0.x line? > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>> On Thu, Feb 25, 2016 at 8:01 AM, Joe Witt < > >> > >>> > > [email protected]> > >> > >>> > > >> > > >> wrote: > >> > >>> > > >> > > >>>>>> > >> > >>> > > >> > > >>>>>>> Given the discussion has stalled i'd like to > turn > >> it > >> > >>> more > >> > >>> > > >> toward > >> > >>> > > >> > a > >> > >>> > > >> > > >>>>>>> proposal as we're at a point now where we need > to > >> > >>> start > >> > >>> > > >> executing > >> > >>> > > >> > > >> some > >> > >>> > > >> > > >>>>>>> of these approaches. We're actually already > >> seeing > >> > it > >> > >>> > take > >> > >>> > > >> form > >> > >>> > > >> > in > >> > >>> > > >> > > >>>>>>> the support/0.5.x branch and the master branch > >> > (which > >> > >>> is > >> > >>> > for > >> > >>> > > >> > 0.6.0 > >> > >>> > > >> > > >> at > >> > >>> > > >> > > >>>>>>> this point). > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> The proposal then for Git processes based on > the > >> > other > >> > >>> > > thread > >> > >>> > > >> [1] > >> > >>> > > >> > > >>>>>>> where we outline a support model: > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> - We will have a branch for each major release > >> line > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> - The branch designated 'master' will be for > the > >> > >>> latest > >> > >>> > > major > >> > >>> > > >> > > >> release > >> > >>> > > >> > > >>>>>>> line under active development > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> - Commits against master should be evaluated > for > >> > >>> whether > >> > >>> > > they > >> > >>> > > >> > > should > >> > >>> > > >> > > >>>>>>> be cherry-picked to other still supported major > >> > >>> release > >> > >>> > > lines > >> > >>> > > >> > > >>>>>>> consistent with the community support model > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> - When a release occurs a signed tag will be > >> > >>> generated and > >> > >>> > > the > >> > >>> > > >> > > >> version > >> > >>> > > >> > > >>>>>>> for that major line will be bumped to the next > >> > >>> incremental > >> > >>> > > >> > release > >> > >>> > > >> > > >>>>>>> snapshot > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> - The next commit on a given major release line > >> that > >> > >>> > > requires a > >> > >>> > > >> > > >> minor > >> > >>> > > >> > > >>>>>>> version change should increment the minor > version > >> > >>> number > >> > >>> > and > >> > >>> > > >> > reset > >> > >>> > > >> > > >>>>>>> incremental to zero > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> - Major version changes should only ever be > >> prompted > >> > >>> from > >> > >>> > > the > >> > >>> > > >> > > master > >> > >>> > > >> > > >>>>>>> branch and should only occur when a commit > >> warrants > >> > >>> > changing > >> > >>> > > >> the > >> > >>> > > >> > > >> major > >> > >>> > > >> > > >>>>>>> version at which point a major release line > branch > >> > >>> should > >> > >>> > be > >> > >>> > > >> > > created > >> > >>> > > >> > > >>>>>>> off of master for the previous major release > line > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> [1] > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >> > >> > >>> > > >> > > > >> > >>> > > >> > > >> > >>> > > >> > >> > >>> > > > >> > >>> > > >> > >>> > >> > > >> > http://mail-archives.apache.org/mod_mbox/nifi-dev/201602.mbox/%3CCALJK9a7bWjff7xXGmUtp3nFV3HRmqbLL1StwkXcf5JdohNPRmg%40mail.gmail.com%3E > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> Thanks > >> > >>> > > >> > > >>>>>>> Joe > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>>>> On Tue, Feb 16, 2016 at 3:13 PM, Joe Witt < > >> > >>> > > [email protected]> > >> > >>> > > >> > > >> wrote: > >> > >>> > > >> > > >>>>>>>> I don't want to kill this thread. It is good > to > >> > >>> discuss > >> > >>> > > >> > specific > >> > >>> > > >> > > >>>>>>>> tooling/procedures. But I do want to get some > >> > >>> consensus > >> > >>> > > >> > > discussion > >> > >>> > > >> > > >>>>>>>> around Tony's original intent (as I read > it). So > >> > >>> kicked > >> > >>> > > off a > >> > >>> > > >> > > >>>>>>>> discussion back at that level. > >> > >>> > > >> > > >>>>>>>> > >> > >>> > > >> > > >>>>>>>> > >> > >>> > > >> > > >>>>>>>> > >> > >>> > > >> > > >>>>>>>> On Tue, Feb 16, 2016 at 8:34 AM, Tony Kurc < > >> > >>> > > [email protected]> > >> > >>> > > >> > > >> wrote: > >> > >>> > > >> > > >>>>>>>>> While I like gitflow, I can't say I like any > of > >> > the > >> > >>> > > plugins > >> > >>> > > >> > that > >> > >>> > > >> > > >> are > >> > >>> > > >> > > >>>>>>> used. > >> > >>> > > >> > > >>>>>>>>> I have worked on some other projects > >> > (unfortunately > >> > >>> not > >> > >>> > > open > >> > >>> > > >> > > >> source) > >> > >>> > > >> > > >>>>>>> that > >> > >>> > > >> > > >>>>>>>>> use a gitflow inspired workflow, without ever > >> > using > >> > >>> a > >> > >>> > > plugin. > >> > >>> > > >> > > Nice > >> > >>> > > >> > > >>>>> side > >> > >>> > > >> > > >>>>>>>>> effect is that I believe this got me better > at > >> > using > >> > >>> > git, > >> > >>> > > and > >> > >>> > > >> > > >>>>> generally > >> > >>> > > >> > > >>>>>>> we > >> > >>> > > >> > > >>>>>>>>> all got better at managing merge pain. > >> > >>> > > >> > > >>>>>>>>> > >> > >>> > > >> > > >>>>>>>>> On merge problems, I think the reason we're > >> > >>> operating > >> > >>> > the > >> > >>> > > way > >> > >>> > > >> > we > >> > >>> > > >> > > >> are > >> > >>> > > >> > > >>>>>>> now is > >> > >>> > > >> > > >>>>>>>>> to avoid merge mayhem. I think the initial > bar > >> > for a > >> > >>> > > patch is > >> > >>> > > >> > > "can > >> > >>> > > >> > > >>> be > >> > >>> > > >> > > >>>>>>>>> merged into master", and we have our friend > >> Travis > >> > >>> to > >> > >>> > make > >> > >>> > > >> this > >> > >>> > > >> > > >> even > >> > >>> > > >> > > >>>>>>> easier > >> > >>> > > >> > > >>>>>>>>> to know upfront. This greatly simplifies > things. > >> > If > >> > >>> a > >> > >>> > > bugfix > >> > >>> > > >> is > >> > >>> > > >> > > >>>>> "patch > >> > >>> > > >> > > >>>>>>>>> needs to be able to apply onto the current > >> release > >> > >>> in > >> > >>> > > >> progress, > >> > >>> > > >> > > >>>>> master, > >> > >>> > > >> > > >>>>>>> and > >> > >>> > > >> > > >>>>>>>>> several other versions we're supporting, with > >> > >>> possibly > >> > >>> > > >> > > drastically > >> > >>> > > >> > > >>>>>>>>> different code", well then things get > >> interesting. > >> > >>> > > >> > > >>>>>>>>> > >> > >>> > > >> > > >>>>>>>>> > >> > >>> > > >> > > >>>>>>>>> > >> > >>> > > >> > > >>>>>>>>> On Mon, Feb 15, 2016 at 12:04 PM, Benson > >> > Margulies < > >> > >>> > > >> > > >>>>>>> [email protected]> > >> > >>> > > >> > > >>>>>>>>> wrote: > >> > >>> > > >> > > >>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>> The issue tracker > >> > >>> > > >> > > >>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>> > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >> > >> > >>> > > >> > > > >> > >>> > > >> > > >> > >>> > > >> > >> > >>> > > > >> > >>> > > >> > >>> > >> > > >> > https://ecosystem.atlassian.net/projects/MJF/issues/MJF-259?filter=allopenissues > >> > >>> > > >> > > >>>>>>>>>> might also prove useful in evaluating it. > >> > >>> > > >> > > >>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>> On Mon, Feb 15, 2016 at 12:03 PM, Benson > >> > Margulies > >> > >>> > > >> > > >>>>>>>>>> <[email protected]> wrote: > >> > >>> > > >> > > >>>>>>>>>>> I tried to use the bitbucket gitflow > plugin. > >> It > >> > >>> worked > >> > >>> > > >> great, > >> > >>> > > >> > > >>>>> until > >> > >>> > > >> > > >>>>>>> it > >> > >>> > > >> > > >>>>>>>>>>> didn't. It would get into terrible, > >> > inexplicable, > >> > >>> > merge > >> > >>> > > >> > > >> problems. > >> > >>> > > >> > > >>>>> No > >> > >>> > > >> > > >>>>>>>>>>> one seemed to be maintaining it. > >> > >>> > > >> > > >>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>> There's a new offering in this dept: > >> > >>> > > >> > > >>>>>>>>>>> > >> > >>> > > >> > > >> https://github.com/egineering-llc/gitflow-helper-maven-plugin > >> > . > >> > >>> > > >> > > >>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>> On Mon, Feb 15, 2016 at 11:41 AM, Adam > Taft < > >> > >>> > > >> > [email protected] > >> > >>> > > >> > > > > >> > >>> > > >> > > >>>>>>> wrote: > >> > >>> > > >> > > >>>>>>>>>>>> One of the harder things with gitflow is > >> using > >> > >>> it in > >> > >>> > > >> > > >> combination > >> > >>> > > >> > > >>>>>>> with > >> > >>> > > >> > > >>>>>>>>>>>> maven. It's ideal that the tags and > releases > >> > are > >> > >>> > > tracking > >> > >>> > > >> > > >>>>> closely > >> > >>> > > >> > > >>>>>>> with > >> > >>> > > >> > > >>>>>>>>>> the > >> > >>> > > >> > > >>>>>>>>>>>> maven pom.xml version. gitflow, on its > own, > >> > >>> doesn't > >> > >>> > > keep > >> > >>> > > >> > the > >> > >>> > > >> > > >> pom > >> > >>> > > >> > > >>>>>>>>>> version > >> > >>> > > >> > > >>>>>>>>>>>> updated with the git release names. > >> > >>> > > >> > > >>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>> Because of the general importance of > keeping > >> > >>> releases > >> > >>> > > and > >> > >>> > > >> > tags > >> > >>> > > >> > > >>>>>>>>>> synchronized > >> > >>> > > >> > > >>>>>>>>>>>> with the pom version, I think whatever we > do, > >> > it > >> > >>> > needs > >> > >>> > > to > >> > >>> > > >> be > >> > >>> > > >> > > >>>>>>> approached > >> > >>> > > >> > > >>>>>>>>>>>> with tools that are available through > maven > >> > >>> rather > >> > >>> > than > >> > >>> > > >> from > >> > >>> > > >> > > >> git. > >> > >>> > > >> > > >>>>>>> The > >> > >>> > > >> > > >>>>>>>>>>>> git-flow plugin (referenced by Thad) > doesn't > >> > >>> directly > >> > >>> > > help > >> > >>> > > >> > > deal > >> > >>> > > >> > > >>>>> with > >> > >>> > > >> > > >>>>>>>>>> this > >> > >>> > > >> > > >>>>>>>>>>>> synchronization, since it's a git tool, > not a > >> > >>> maven > >> > >>> > > tool. > >> > >>> > > >> > > >>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>> I've been using, with reasonable success, > the > >> > >>> > jgitflow > >> > >>> > > [1] > >> > >>> > > >> > > >>>>> plugin, > >> > >>> > > >> > > >>>>>>> which > >> > >>> > > >> > > >>>>>>>>>>>> does a reasonable job of following the > >> gitflow > >> > >>> model > >> > >>> > > for a > >> > >>> > > >> > > >> maven > >> > >>> > > >> > > >>>>>>>>>> project. > >> > >>> > > >> > > >>>>>>>>>>>> I don't recommend this plugin for NIFI, > >> because > >> > >>> it > >> > >>> > > insists > >> > >>> > > >> > > that > >> > >>> > > >> > > >>>>> the > >> > >>> > > >> > > >>>>>>>>>> master > >> > >>> > > >> > > >>>>>>>>>>>> branch is strictly used for published > release > >> > >>> tags > >> > >>> > (as > >> > >>> > > per > >> > >>> > > >> > the > >> > >>> > > >> > > >>>>>>> strict > >> > >>> > > >> > > >>>>>>>>>>>> gitflow workflow). I just mention this, > in > >> > >>> reference > >> > >>> > > to > >> > >>> > > >> how > >> > >>> > > >> > > >> some > >> > >>> > > >> > > >>>>>>>>>> plugins > >> > >>> > > >> > > >>>>>>>>>>>> are tackling the gitflow and maven > >> > >>> synchronization > >> > >>> > > issue. > >> > >>> > > >> > > >>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>> [1] http://jgitflow.bitbucket.org/ > >> > >>> > > >> > > >>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>> On Sun, Feb 14, 2016 at 10:48 PM, Thad > >> Guidry < > >> > >>> > > >> > > >>>>> [email protected] > >> > >>> > > >> > > >>>>>>>> > >> > >>> > > >> > > >>>>>>>>>> wrote: > >> > >>> > > >> > > >>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>>> Your on the right track / idea with > >> Git-flow. > >> > >>> Your > >> > >>> > > >> Master > >> > >>> > > >> > > >>>>> become > >> > >>> > > >> > > >>>>>>>>>> primary > >> > >>> > > >> > > >>>>>>>>>>>>> development of next release (with feature > >> > >>> branches > >> > >>> > > off of > >> > >>> > > >> > > >> it).. > >> > >>> > > >> > > >>>>>>> while > >> > >>> > > >> > > >>>>>>>>>> you > >> > >>> > > >> > > >>>>>>>>>>>>> continue to have release branches that > can > >> > have > >> > >>> hot > >> > >>> > > fix > >> > >>> > > >> > > >> branches > >> > >>> > > >> > > >>>>>>> off of > >> > >>> > > >> > > >>>>>>>>>>>>> them. (don't use Master as your release > >> > branch > >> > >>> ! - > >> > >>> > > bad > >> > >>> > > >> > > >>>>> practice ! > >> > >>> > > >> > > >>>>>>> ) > >> > >>> > > >> > > >>>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>>> Here is the Git-flow cheat sheet to make > it > >> > >>> easy for > >> > >>> > > >> > everyone > >> > >>> > > >> > > >> to > >> > >>> > > >> > > >>>>>>>>>>>>> understand... just scroll it down to gain > >> the > >> > >>> > > >> > understanding. > >> > >>> > > >> > > >> Its > >> > >>> > > >> > > >>>>>>> really > >> > >>> > > >> > > >>>>>>>>>>>>> that easy. > >> > >>> > > >> > > >>>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>>> > >> > >>> http://danielkummer.github.io/git-flow-cheatsheet/ > >> > >>> > > >> > > >>>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>>> Most large projects have moved into using > >> > >>> git-flow > >> > >>> > ... > >> > >>> > > >> and > >> > >>> > > >> > > >> tools > >> > >>> > > >> > > >>>>>>> like > >> > >>> > > >> > > >>>>>>>>>>>>> Eclipse Mars, IntelliJ, Sourcetree, > >> etc...have > >> > >>> > > Git-flow > >> > >>> > > >> > > either > >> > >>> > > >> > > >>>>>>> built > >> > >>> > > >> > > >>>>>>>>>> in or > >> > >>> > > >> > > >>>>>>>>>>>>> plugin available now. If you want to > live > >> on > >> > >>> the > >> > >>> > > command > >> > >>> > > >> > > >> line, > >> > >>> > > >> > > >>>>>>> then > >> > >>> > > >> > > >>>>>>>>>> that > >> > >>> > > >> > > >>>>>>>>>>>>> is handled easily by the instructions in > the > >> > >>> above > >> > >>> > > link. > >> > >>> > > >> > > >>>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>>>>> Thad > >> > >>> > > >> > > >>>>>>>>>>>>> +ThadGuidry < > >> > https://www.google.com/+ThadGuidry > >> > >>> > > >> > >>> > > >> > > >>>>>>>>>>>>> > >> > >>> > > >> > > >>>>>>>>>> > >> > >>> > > >> > > >>>>>>> > >> > >>> > > >> > > >>>>> > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >>> > >> > >>> > > >> > > >> > >> > >>> > > >> > > > >> > >>> > > >> > > > >> > >>> > > >> > > >> > >>> > > >> > >> > >>> > > > >> > >>> > > >> > >>> > >> > >> > >> > >> > >> > > > >> > > >> >
