nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@apache.org>
Subject Re: [DISCUSS] git branching model
Date Mon, 04 Apr 2016 17:14:16 GMT
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 <matt.c.gilman@gmail.com> 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 <trkurc@gmail.com> 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 <matt.c.gilman@gmail.com>
>> 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 <matt.c.gilman@gmail.com>
>> > 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 <matt.c.gilman@gmail.com>
>> > > 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 <aldrinpiri@gmail.com>
>> > >> 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 <mattyb149@gmail.com>
>> > >>> 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 <joe.witt@gmail.com>
>> > wrote:
>> > >>> >
>> > >>> > > I too prefer option 1
>> > >>> > >
>> > >>> > > On Tue, Mar 29, 2016 at 8:21 AM, Brandon DeVries <brd@jhu.edu>
>> > >>> 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 <trkurc@gmail.com>
>> > >>> wrote:
>> > >>> > > >
>> > >>> > > >> I like option 1
>> > >>> > > >> On Mar 29, 2016 10:03 AM, "Matt Gilman" <
>> > matt.c.gilman@gmail.com>
>> > >>> > > 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 <
>> > >>> > > r.p.miskin@gmail.com>
>> > >>> > > >> > 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 <
>> > aldrinpiri@gmail.com
>> > >>> >
>> > >>> > > 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 <
>> > >>> trkurc@gmail.com>
>> > >>> > > 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 <
>> > >>> > > >> r.p.miskin@gmail.com
>> > >>> > > >> > >
>> > >>> > > >> > > >> 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 <
>> jvwing@gmail.com
>> > >
>> > >>> > 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 <
>> > >>> > joe.witt@gmail.com>
>> > >>> > > >> > 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 <
>> > >>> > jvwing@gmail.com
>> > >>> > > >
>> > >>> > > >> > > 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 <
>> > >>> > > joe.witt@gmail.com>
>> > >>> > > >> > > >> 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 <
>> > >>> > > joe.witt@gmail.com>
>> > >>> > > >> > > >> 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 <
>> > >>> > > trkurc@gmail.com>
>> > >>> > > >> > > >> 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 <
>> > >>> > > >> > > >>>>>>> bimargulies@gmail.com>
>> > >>> > > >> > > >>>>>>>>> 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
>> > >>> > > >> > > >>>>>>>>>> <bimargulies@gmail.com> 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 <
>> > >>> > > >> > adam@adamtaft.com
>> > >>> > > >> > > >
>> > >>> > > >> > > >>>>>>> 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 <
>> > >>> > > >> > > >>>>> thadguidry@gmail.com
>> > >>> > > >> > > >>>>>>>>
>> > >>> > > >> > > >>>>>>>>>> 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
>> > >>> >
>> > >>> > > >> > > >>>>>>>>>>>>>
>> > >>> > > >> > > >>>>>>>>>>
>> > >>> > > >> > > >>>>>>>
>> > >>> > > >> > > >>>>>
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>>
>> > >>> > > >> > > >>
>> > >>> > > >> > >
>> > >>> > > >> > >
>> > >>> > > >> >
>> > >>> > > >>
>> > >>> > >
>> > >>> >
>> > >>>
>> > >>
>> > >>
>> > >
>> >
>>

Mime
View raw message