Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[Swapnil Daingade]

I did not understand the difference between Proposal A and Alt 1 (the way
Adam described it).
Seem quite similar to me

+1 A or Alt1
+1 B

Regards
Swapnil


On Fri, Dec 4, 2015 at 8:42 AM, Darin Johnson 
wrote:

> My experience with alt 1 is it takes a lot of discipline or it devolves
> into develop just being master.  I'd be curious how others have found it.
> On Dec 3, 2015 10:07 PM, "Darin Johnson"  wrote:
>
> > +1 A, +1 B.
> > On Dec 3, 2015 7:12 PM, "Sarjeet Singh" 
> wrote:
> >
> >> +1 for Proposal A -> Alt 1, and +1 for Proposal B.
> >>
> >> Should we also maintain 'develop' & 'master' branch as described on
> >> nvie.com,
> >> it was easy to read through the branching model, and understand the
> >> branching flow without any complexity involved?
> >>
> >> Btw, Good pro/con list with references. thanks Adam!!
> >>
> >> -Sarjeet
> >>
> >> On Thu, Dec 3, 2015 at 2:49 PM, Santosh Marella 
> >> wrote:
> >>
> >> > Yup.
> >> >
> >> > +1 for Proposal A -> Alternative 1.
> >> > +1 for Proposal B
> >> >
> >> > Santosh
> >> >
> >> > On Thu, Dec 3, 2015 at 1:03 PM, yuliya Feldman
> >>  >> > >
> >> > wrote:
> >> >
> >> > > I fully second Todd.
> >> > > Thanks,Yuliya
> >> > >   From: Todd Richmond 
> >> > >  To: dev@myriad.incubator.apache.org
> >> > >  Sent: Thursday, December 3, 2015 8:59 AM
> >> > >  Subject: Re: [PROPOSAL(s)] Use Release Branches, and Delete
> Obsolete
> >> > > Branches
> >> > >
> >> > > excellent pro/con list
> >> > >
> >> > > +1 for either A or + .5 for Alt 1. A branch is easy to follow and
> >> allows
> >> > > for long term patch support. Each new 0.x.y patch release becomes
> the
> >> > only
> >> > > “supported” 0.x version but more than one “x” can be supported
> >> > > simultaneously
> >> > >
> >> > > Alt 2 tags work best when you release very often (such as monthly)
> to
> >> > > users who are willing to upgrade and so can quickly deprecate
> previous
> >> > > releases. Cherry-picking is more manual effort and possibly error
> >> prone
> >> > as
> >> > > the committer count grows
> >> > >
> >> > > +1 for proposal B. feature branches can usually be done on private
> >> forks
> >> > > instead and should definitely be removed once the feature is merged
> to
> >> > > develop
> >> > >
> >> > >   Todd
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > > On Dec 3, 2015, at 12:36 AM, Adam Bordelon 
> >> wrote:
> >> > > >
> >> > > > Proposal A: Use Release Branches
> >> > > > I propose that we create a '0.1.x' branch that will contain all of
> >> the
> >> > > > 0.1.0-rc tags, the final 0.1.0 release tag, and any tags related
> to
> >> > > hotfix
> >> > > > releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can
> >> > > cherry-pick
> >> > > > fixes from master directly on top of the 0.1.0 tag in the 0.1.x
> >> branch,
> >> > > and
> >> > > > we'll iterate on its rc's in the 0.1.x branch. Development for
> >> > > > features/fixes for 0.2.0 go into the master branch, and whenever
> >> 0.2.0
> >> > is
> >> > > > feature-complete/ready, we'll cut the new '0.2.x' branch from
> master
> >> > and
> >> > > > tag a 0.2.0-rc1, then cherry pick any necessary fixes from master
> >> into
> >> > > > 0.2.x, for future release candidates and hotfix releases.
> >> > > > + Easy to create/review github PRs to merge fixes into release
> >> > candidates
> >> > > > and hotfix releases.
> >> > > > + Release candidates and hotfixes are handled in the appropriate
> >> > release
> >> > > > branch, while normal development can continue in master.
> >> > > > + Minimal additional branches/commands required; no need for
> >> ephemeral
> >> > > > branches for each release (candidate).
> >> > > >
> >> > > > Alternative 1: Follow
> >> > > >
> >> >
> >>
> http://nvie.com/posts/a-successful-git-branching-model/#release-branches
> >> > > > My proposal is similar to the model described by nvie except that
> we
> >> > use
> >> > > > the myriad 'master' branch for what he calls the 'develop' branch,
> >> and
> >> > we
> >> > > > use our 0.1.x,0.2.x release branches as longer-lived branches for
> >> > hotfix
> >> > > > releases. (Note: Feature branches are a separate discussion,
> >> unrelated
> >> > to
> >> > > > release management.)
> >> > > > + Easy to follow guide.
> >> > > > + Good separation of concerns/responsibility.
> >> > > > - Doesn't explain how release candidates are handled.
> >> > > > - So many branches.
> >> > > >
> >> > > > Alternative 2: Use tags for releases, no branches (like Mesos
> does)
> >> > > > See the discussion at:
> >> > > >
> >> > >
> >> >
> >>
> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
> >> > > > + No mess of branches in the repo; no merging between branches.
> >> > > > + Since release candidates and releases are cherry-picked and
> >> tagged,
> >> > > > normal development can continue on master without
> >> > > interruption/corruption.
> >> > > > - Github PRs cannot use a tag (Dealbreaker?).
> >> > > > http://stackoverflow.com/a/12279290/4056606
> >> > > >
> >>

Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[Darin Johnson]

My experience with alt 1 is it takes a lot of discipline or it devolves
into develop just being master.  I'd be curious how others have found it.
On Dec 3, 2015 10:07 PM, "Darin Johnson"  wrote:

> +1 A, +1 B.
> On Dec 3, 2015 7:12 PM, "Sarjeet Singh"  wrote:
>
>> +1 for Proposal A -> Alt 1, and +1 for Proposal B.
>>
>> Should we also maintain 'develop' & 'master' branch as described on
>> nvie.com,
>> it was easy to read through the branching model, and understand the
>> branching flow without any complexity involved?
>>
>> Btw, Good pro/con list with references. thanks Adam!!
>>
>> -Sarjeet
>>
>> On Thu, Dec 3, 2015 at 2:49 PM, Santosh Marella 
>> wrote:
>>
>> > Yup.
>> >
>> > +1 for Proposal A -> Alternative 1.
>> > +1 for Proposal B
>> >
>> > Santosh
>> >
>> > On Thu, Dec 3, 2015 at 1:03 PM, yuliya Feldman
>> > > >
>> > wrote:
>> >
>> > > I fully second Todd.
>> > > Thanks,Yuliya
>> > >   From: Todd Richmond 
>> > >  To: dev@myriad.incubator.apache.org
>> > >  Sent: Thursday, December 3, 2015 8:59 AM
>> > >  Subject: Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete
>> > > Branches
>> > >
>> > > excellent pro/con list
>> > >
>> > > +1 for either A or + .5 for Alt 1. A branch is easy to follow and
>> allows
>> > > for long term patch support. Each new 0.x.y patch release becomes the
>> > only
>> > > “supported” 0.x version but more than one “x” can be supported
>> > > simultaneously
>> > >
>> > > Alt 2 tags work best when you release very often (such as monthly) to
>> > > users who are willing to upgrade and so can quickly deprecate previous
>> > > releases. Cherry-picking is more manual effort and possibly error
>> prone
>> > as
>> > > the committer count grows
>> > >
>> > > +1 for proposal B. feature branches can usually be done on private
>> forks
>> > > instead and should definitely be removed once the feature is merged to
>> > > develop
>> > >
>> > >   Todd
>> > >
>> > >
>> > >
>> > >
>> > > > On Dec 3, 2015, at 12:36 AM, Adam Bordelon 
>> wrote:
>> > > >
>> > > > Proposal A: Use Release Branches
>> > > > I propose that we create a '0.1.x' branch that will contain all of
>> the
>> > > > 0.1.0-rc tags, the final 0.1.0 release tag, and any tags related to
>> > > hotfix
>> > > > releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can
>> > > cherry-pick
>> > > > fixes from master directly on top of the 0.1.0 tag in the 0.1.x
>> branch,
>> > > and
>> > > > we'll iterate on its rc's in the 0.1.x branch. Development for
>> > > > features/fixes for 0.2.0 go into the master branch, and whenever
>> 0.2.0
>> > is
>> > > > feature-complete/ready, we'll cut the new '0.2.x' branch from master
>> > and
>> > > > tag a 0.2.0-rc1, then cherry pick any necessary fixes from master
>> into
>> > > > 0.2.x, for future release candidates and hotfix releases.
>> > > > + Easy to create/review github PRs to merge fixes into release
>> > candidates
>> > > > and hotfix releases.
>> > > > + Release candidates and hotfixes are handled in the appropriate
>> > release
>> > > > branch, while normal development can continue in master.
>> > > > + Minimal additional branches/commands required; no need for
>> ephemeral
>> > > > branches for each release (candidate).
>> > > >
>> > > > Alternative 1: Follow
>> > > >
>> >
>> http://nvie.com/posts/a-successful-git-branching-model/#release-branches
>> > > > My proposal is similar to the model described by nvie except that we
>> > use
>> > > > the myriad 'master' branch for what he calls the 'develop' branch,
>> and
>> > we
>> > > > use our 0.1.x,0.2.x release branches as longer-lived branches for
>> > hotfix
>> > > > releases. (Note: Feature branches are a separate discussion,
>> unrelated
>> > to
>> > > > release management.)
>> > > > + Easy to follow guide.
>> > > > + Good separation of concerns/responsibility.
>> > > > - Doesn't explain how release candidates are handled.
>> > > > - So many branches.
>> > > >
>> > > > Alternative 2: Use tags for releases, no branches (like Mesos does)
>> > > > See the discussion at:
>> > > >
>> > >
>> >
>> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
>> > > > + No mess of branches in the repo; no merging between branches.
>> > > > + Since release candidates and releases are cherry-picked and
>> tagged,
>> > > > normal development can continue on master without
>> > > interruption/corruption.
>> > > > - Github PRs cannot use a tag (Dealbreaker?).
>> > > > http://stackoverflow.com/a/12279290/4056606
>> > > >
>> > > > Please let me know your thoughts on release branches. I went ahead
>> and
>> > > > created the '0.1.x' branch from the 0.1.0-rc3 tag so you can check
>> it
>> > out
>> > > > and play around, and so you can push 0.2.0 features to master
>> without
>> > > > worrying about messing up the 0.1.0 release. We can cherry-pick any
>> > > > rc4/0.1.1 patches out of master, and we can always
>> delete/rename/reorg
>> > > the
>> > > > release branch later if desired.
>> > > >
>> > >
>> >
>> https://git-

Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[Darin Johnson]

+1 A, +1 B.
On Dec 3, 2015 7:12 PM, "Sarjeet Singh"  wrote:

> +1 for Proposal A -> Alt 1, and +1 for Proposal B.
>
> Should we also maintain 'develop' & 'master' branch as described on
> nvie.com,
> it was easy to read through the branching model, and understand the
> branching flow without any complexity involved?
>
> Btw, Good pro/con list with references. thanks Adam!!
>
> -Sarjeet
>
> On Thu, Dec 3, 2015 at 2:49 PM, Santosh Marella 
> wrote:
>
> > Yup.
> >
> > +1 for Proposal A -> Alternative 1.
> > +1 for Proposal B
> >
> > Santosh
> >
> > On Thu, Dec 3, 2015 at 1:03 PM, yuliya Feldman
>  > >
> > wrote:
> >
> > > I fully second Todd.
> > > Thanks,Yuliya
> > >   From: Todd Richmond 
> > >  To: dev@myriad.incubator.apache.org
> > >  Sent: Thursday, December 3, 2015 8:59 AM
> > >  Subject: Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete
> > > Branches
> > >
> > > excellent pro/con list
> > >
> > > +1 for either A or + .5 for Alt 1. A branch is easy to follow and
> allows
> > > for long term patch support. Each new 0.x.y patch release becomes the
> > only
> > > “supported” 0.x version but more than one “x” can be supported
> > > simultaneously
> > >
> > > Alt 2 tags work best when you release very often (such as monthly) to
> > > users who are willing to upgrade and so can quickly deprecate previous
> > > releases. Cherry-picking is more manual effort and possibly error prone
> > as
> > > the committer count grows
> > >
> > > +1 for proposal B. feature branches can usually be done on private
> forks
> > > instead and should definitely be removed once the feature is merged to
> > > develop
> > >
> > >   Todd
> > >
> > >
> > >
> > >
> > > > On Dec 3, 2015, at 12:36 AM, Adam Bordelon 
> wrote:
> > > >
> > > > Proposal A: Use Release Branches
> > > > I propose that we create a '0.1.x' branch that will contain all of
> the
> > > > 0.1.0-rc tags, the final 0.1.0 release tag, and any tags related to
> > > hotfix
> > > > releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can
> > > cherry-pick
> > > > fixes from master directly on top of the 0.1.0 tag in the 0.1.x
> branch,
> > > and
> > > > we'll iterate on its rc's in the 0.1.x branch. Development for
> > > > features/fixes for 0.2.0 go into the master branch, and whenever
> 0.2.0
> > is
> > > > feature-complete/ready, we'll cut the new '0.2.x' branch from master
> > and
> > > > tag a 0.2.0-rc1, then cherry pick any necessary fixes from master
> into
> > > > 0.2.x, for future release candidates and hotfix releases.
> > > > + Easy to create/review github PRs to merge fixes into release
> > candidates
> > > > and hotfix releases.
> > > > + Release candidates and hotfixes are handled in the appropriate
> > release
> > > > branch, while normal development can continue in master.
> > > > + Minimal additional branches/commands required; no need for
> ephemeral
> > > > branches for each release (candidate).
> > > >
> > > > Alternative 1: Follow
> > > >
> > http://nvie.com/posts/a-successful-git-branching-model/#release-branches
> > > > My proposal is similar to the model described by nvie except that we
> > use
> > > > the myriad 'master' branch for what he calls the 'develop' branch,
> and
> > we
> > > > use our 0.1.x,0.2.x release branches as longer-lived branches for
> > hotfix
> > > > releases. (Note: Feature branches are a separate discussion,
> unrelated
> > to
> > > > release management.)
> > > > + Easy to follow guide.
> > > > + Good separation of concerns/responsibility.
> > > > - Doesn't explain how release candidates are handled.
> > > > - So many branches.
> > > >
> > > > Alternative 2: Use tags for releases, no branches (like Mesos does)
> > > > See the discussion at:
> > > >
> > >
> >
> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
> > > > + No mess of branches in the repo; no merging between branches.
> > > > + Since release candidates and releases are cherry-picked and tagged,
> > > > normal development can continue on master without
> > > interruption/corruption.
> > > > - Github PRs cannot use a tag (Dealbreaker?).
> > > > http://stackoverflow.com/a/12279290/4056606
> > > >
> > > > Please let me know your thoughts on release branches. I went ahead
> and
> > > > created the '0.1.x' branch from the 0.1.0-rc3 tag so you can check it
> > out
> > > > and play around, and so you can push 0.2.0 features to master without
> > > > worrying about messing up the 0.1.0 release. We can cherry-pick any
> > > > rc4/0.1.1 patches out of master, and we can always
> delete/rename/reorg
> > > the
> > > > release branch later if desired.
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-myriad.git;a=shortlog;h=refs/heads/0.1.x
> > > >
> > > >
> > > >
> > > > Proposal B: Delete all these obsolete branches from the Apache git
> > repo:
> > > > 9/23/15 phase1 (72 behind master)
> > > > 8/12/15 constraints (kensipe)
> > > > 8/12/15 myriadha (kensipe)
> > > > 8/10/15 issue_14 (smarella)
> > > > 7/17

Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[Sarjeet Singh]

+1 for Proposal A -> Alt 1, and +1 for Proposal B.

Should we also maintain 'develop' & 'master' branch as described on nvie.com,
it was easy to read through the branching model, and understand the
branching flow without any complexity involved?

Btw, Good pro/con list with references. thanks Adam!!

-Sarjeet

On Thu, Dec 3, 2015 at 2:49 PM, Santosh Marella 
wrote:

> Yup.
>
> +1 for Proposal A -> Alternative 1.
> +1 for Proposal B
>
> Santosh
>
> On Thu, Dec 3, 2015 at 1:03 PM, yuliya Feldman  >
> wrote:
>
> > I fully second Todd.
> > Thanks,Yuliya
> >   From: Todd Richmond 
> >  To: dev@myriad.incubator.apache.org
> >  Sent: Thursday, December 3, 2015 8:59 AM
> >  Subject: Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete
> > Branches
> >
> > excellent pro/con list
> >
> > +1 for either A or + .5 for Alt 1. A branch is easy to follow and allows
> > for long term patch support. Each new 0.x.y patch release becomes the
> only
> > “supported” 0.x version but more than one “x” can be supported
> > simultaneously
> >
> > Alt 2 tags work best when you release very often (such as monthly) to
> > users who are willing to upgrade and so can quickly deprecate previous
> > releases. Cherry-picking is more manual effort and possibly error prone
> as
> > the committer count grows
> >
> > +1 for proposal B. feature branches can usually be done on private forks
> > instead and should definitely be removed once the feature is merged to
> > develop
> >
> >   Todd
> >
> >
> >
> >
> > > On Dec 3, 2015, at 12:36 AM, Adam Bordelon  wrote:
> > >
> > > Proposal A: Use Release Branches
> > > I propose that we create a '0.1.x' branch that will contain all of the
> > > 0.1.0-rc tags, the final 0.1.0 release tag, and any tags related to
> > hotfix
> > > releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can
> > cherry-pick
> > > fixes from master directly on top of the 0.1.0 tag in the 0.1.x branch,
> > and
> > > we'll iterate on its rc's in the 0.1.x branch. Development for
> > > features/fixes for 0.2.0 go into the master branch, and whenever 0.2.0
> is
> > > feature-complete/ready, we'll cut the new '0.2.x' branch from master
> and
> > > tag a 0.2.0-rc1, then cherry pick any necessary fixes from master into
> > > 0.2.x, for future release candidates and hotfix releases.
> > > + Easy to create/review github PRs to merge fixes into release
> candidates
> > > and hotfix releases.
> > > + Release candidates and hotfixes are handled in the appropriate
> release
> > > branch, while normal development can continue in master.
> > > + Minimal additional branches/commands required; no need for ephemeral
> > > branches for each release (candidate).
> > >
> > > Alternative 1: Follow
> > >
> http://nvie.com/posts/a-successful-git-branching-model/#release-branches
> > > My proposal is similar to the model described by nvie except that we
> use
> > > the myriad 'master' branch for what he calls the 'develop' branch, and
> we
> > > use our 0.1.x,0.2.x release branches as longer-lived branches for
> hotfix
> > > releases. (Note: Feature branches are a separate discussion, unrelated
> to
> > > release management.)
> > > + Easy to follow guide.
> > > + Good separation of concerns/responsibility.
> > > - Doesn't explain how release candidates are handled.
> > > - So many branches.
> > >
> > > Alternative 2: Use tags for releases, no branches (like Mesos does)
> > > See the discussion at:
> > >
> >
> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
> > > + No mess of branches in the repo; no merging between branches.
> > > + Since release candidates and releases are cherry-picked and tagged,
> > > normal development can continue on master without
> > interruption/corruption.
> > > - Github PRs cannot use a tag (Dealbreaker?).
> > > http://stackoverflow.com/a/12279290/4056606
> > >
> > > Please let me know your thoughts on release branches. I went ahead and
> > > created the '0.1.x' branch from the 0.1.0-rc3 tag so you can check it
> out
> > > and play around, and so you can push 0.2.0 features to master without
> > > worrying about messing up the 0.1.0 release. We can cherry-pick any
> > > rc4/0.1.1 patches out of master, and we can always delete/rename/reorg
> > the
> > > release branch later if desired.
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-myriad.git;a=shortlog;h=refs/heads/0.1.x
> > >
> > >
> > >
> > > Proposal B: Delete all these obsolete branches from the Apache git
> repo:
> > > 9/23/15 phase1 (72 behind master)
> > > 8/12/15 constraints (kensipe)
> > > 8/12/15 myriadha (kensipe)
> > > 8/10/15 issue_14 (smarella)
> > > 7/17/15 executor-only-application (kensipe)
> > > 6/11/15 multi-project (kensipe)
> > > 6/11/15 docker-image (kensipe)
> > > 3/04/15 issue_16 (mohit)
> > > If nobody speaks up to save any/all of these, I'll delete them next
> week.
> > > (Note that most of these still live on in the old github repo, if you
> > look
> > > closely.)
> >
> >
> >
> >
>

Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[Santosh Marella]

Yup.

+1 for Proposal A -> Alternative 1.
+1 for Proposal B

Santosh

On Thu, Dec 3, 2015 at 1:03 PM, yuliya Feldman 
wrote:

> I fully second Todd.
> Thanks,Yuliya
>   From: Todd Richmond 
>  To: dev@myriad.incubator.apache.org
>  Sent: Thursday, December 3, 2015 8:59 AM
>  Subject: Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete
> Branches
>
> excellent pro/con list
>
> +1 for either A or + .5 for Alt 1. A branch is easy to follow and allows
> for long term patch support. Each new 0.x.y patch release becomes the only
> “supported” 0.x version but more than one “x” can be supported
> simultaneously
>
> Alt 2 tags work best when you release very often (such as monthly) to
> users who are willing to upgrade and so can quickly deprecate previous
> releases. Cherry-picking is more manual effort and possibly error prone as
> the committer count grows
>
> +1 for proposal B. feature branches can usually be done on private forks
> instead and should definitely be removed once the feature is merged to
> develop
>
>   Todd
>
>
>
>
> > On Dec 3, 2015, at 12:36 AM, Adam Bordelon  wrote:
> >
> > Proposal A: Use Release Branches
> > I propose that we create a '0.1.x' branch that will contain all of the
> > 0.1.0-rc tags, the final 0.1.0 release tag, and any tags related to
> hotfix
> > releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can
> cherry-pick
> > fixes from master directly on top of the 0.1.0 tag in the 0.1.x branch,
> and
> > we'll iterate on its rc's in the 0.1.x branch. Development for
> > features/fixes for 0.2.0 go into the master branch, and whenever 0.2.0 is
> > feature-complete/ready, we'll cut the new '0.2.x' branch from master and
> > tag a 0.2.0-rc1, then cherry pick any necessary fixes from master into
> > 0.2.x, for future release candidates and hotfix releases.
> > + Easy to create/review github PRs to merge fixes into release candidates
> > and hotfix releases.
> > + Release candidates and hotfixes are handled in the appropriate release
> > branch, while normal development can continue in master.
> > + Minimal additional branches/commands required; no need for ephemeral
> > branches for each release (candidate).
> >
> > Alternative 1: Follow
> > http://nvie.com/posts/a-successful-git-branching-model/#release-branches
> > My proposal is similar to the model described by nvie except that we use
> > the myriad 'master' branch for what he calls the 'develop' branch, and we
> > use our 0.1.x,0.2.x release branches as longer-lived branches for hotfix
> > releases. (Note: Feature branches are a separate discussion, unrelated to
> > release management.)
> > + Easy to follow guide.
> > + Good separation of concerns/responsibility.
> > - Doesn't explain how release candidates are handled.
> > - So many branches.
> >
> > Alternative 2: Use tags for releases, no branches (like Mesos does)
> > See the discussion at:
> >
> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
> > + No mess of branches in the repo; no merging between branches.
> > + Since release candidates and releases are cherry-picked and tagged,
> > normal development can continue on master without
> interruption/corruption.
> > - Github PRs cannot use a tag (Dealbreaker?).
> > http://stackoverflow.com/a/12279290/4056606
> >
> > Please let me know your thoughts on release branches. I went ahead and
> > created the '0.1.x' branch from the 0.1.0-rc3 tag so you can check it out
> > and play around, and so you can push 0.2.0 features to master without
> > worrying about messing up the 0.1.0 release. We can cherry-pick any
> > rc4/0.1.1 patches out of master, and we can always delete/rename/reorg
> the
> > release branch later if desired.
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-myriad.git;a=shortlog;h=refs/heads/0.1.x
> >
> >
> >
> > Proposal B: Delete all these obsolete branches from the Apache git repo:
> > 9/23/15 phase1 (72 behind master)
> > 8/12/15 constraints (kensipe)
> > 8/12/15 myriadha (kensipe)
> > 8/10/15 issue_14 (smarella)
> > 7/17/15 executor-only-application (kensipe)
> > 6/11/15 multi-project (kensipe)
> > 6/11/15 docker-image (kensipe)
> > 3/04/15 issue_16 (mohit)
> > If nobody speaks up to save any/all of these, I'll delete them next week.
> > (Note that most of these still live on in the old github repo, if you
> look
> > closely.)
>
>
>
>

Re: Myriad's website is live!

[Santosh Marella]

Pretty cool! Great to see Myriad's website up and running.

On Dec 3, 2015 5:20 AM, "Brandon Gulla"  wrote:

> Great job!
>
> On Thu, Dec 3, 2015 at 7:17 AM, Jim Klucar  wrote:
>
> > Awesome. Hopefully we can push a post about the release soon!
> >
> > On Wed, Dec 2, 2015 at 10:14 PM, Sarjeet Singh <
> sarjeetsi...@maprtech.com>
> > wrote:
> >
> > > Good one, Mohit. Kudos to make it work, and Others for contributing to
> > > build the website!!
> > >
> > > Website looks great, and it has all necessary information to get it
> going
> > > from here. Navigated around the website and it feels nice :)
> > >
> > > -Sarjeet
> > >
> > > On Wed, Dec 2, 2015 at 7:00 PM, mohit soni 
> > > wrote:
> > >
> > > > Apache Myriad website is finally live, please go and checkout it out
> > for
> > > > real here !
> > > >
> > > > I was able to identify the root cause which was preventing jekyll
> from
> > > > building the content correctly. Apparently, Jekyll does not like the
> > > > comments place on top of the Liquid templates, for that matter it
> > doesn't
> > > > like anything (even newlines) before the triple dashes ''
> section.
> > > Once
> > > > I moved the triple dash section on top of the files, the rendering
> > > started
> > > > working just fine.
> > > >
> > > > Cheers!
> > > > Mohit
> > > >
> > >
> >
>
>
>
> --
> Brandon
>

Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[yuliya Feldman]

I fully second Todd.
Thanks,Yuliya
  From: Todd Richmond 
 To: dev@myriad.incubator.apache.org 
 Sent: Thursday, December 3, 2015 8:59 AM
 Subject: Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches
   
excellent pro/con list

+1 for either A or + .5 for Alt 1. A branch is easy to follow and allows for 
long term patch support. Each new 0.x.y patch release becomes the only 
“supported” 0.x version but more than one “x” can be supported simultaneously

Alt 2 tags work best when you release very often (such as monthly) to users who 
are willing to upgrade and so can quickly deprecate previous releases. 
Cherry-picking is more manual effort and possibly error prone as the committer 
count grows

+1 for proposal B. feature branches can usually be done on private forks 
instead and should definitely be removed once the feature is merged to develop

  Todd




> On Dec 3, 2015, at 12:36 AM, Adam Bordelon  wrote:
> 
> Proposal A: Use Release Branches
> I propose that we create a '0.1.x' branch that will contain all of the
> 0.1.0-rc tags, the final 0.1.0 release tag, and any tags related to hotfix
> releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can cherry-pick
> fixes from master directly on top of the 0.1.0 tag in the 0.1.x branch, and
> we'll iterate on its rc's in the 0.1.x branch. Development for
> features/fixes for 0.2.0 go into the master branch, and whenever 0.2.0 is
> feature-complete/ready, we'll cut the new '0.2.x' branch from master and
> tag a 0.2.0-rc1, then cherry pick any necessary fixes from master into
> 0.2.x, for future release candidates and hotfix releases.
> + Easy to create/review github PRs to merge fixes into release candidates
> and hotfix releases.
> + Release candidates and hotfixes are handled in the appropriate release
> branch, while normal development can continue in master.
> + Minimal additional branches/commands required; no need for ephemeral
> branches for each release (candidate).
> 
> Alternative 1: Follow
> http://nvie.com/posts/a-successful-git-branching-model/#release-branches
> My proposal is similar to the model described by nvie except that we use
> the myriad 'master' branch for what he calls the 'develop' branch, and we
> use our 0.1.x,0.2.x release branches as longer-lived branches for hotfix
> releases. (Note: Feature branches are a separate discussion, unrelated to
> release management.)
> + Easy to follow guide.
> + Good separation of concerns/responsibility.
> - Doesn't explain how release candidates are handled.
> - So many branches.
> 
> Alternative 2: Use tags for releases, no branches (like Mesos does)
> See the discussion at:
> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
> + No mess of branches in the repo; no merging between branches.
> + Since release candidates and releases are cherry-picked and tagged,
> normal development can continue on master without interruption/corruption.
> - Github PRs cannot use a tag (Dealbreaker?).
> http://stackoverflow.com/a/12279290/4056606
> 
> Please let me know your thoughts on release branches. I went ahead and
> created the '0.1.x' branch from the 0.1.0-rc3 tag so you can check it out
> and play around, and so you can push 0.2.0 features to master without
> worrying about messing up the 0.1.0 release. We can cherry-pick any
> rc4/0.1.1 patches out of master, and we can always delete/rename/reorg the
> release branch later if desired.
> https://git-wip-us.apache.org/repos/asf?p=incubator-myriad.git;a=shortlog;h=refs/heads/0.1.x
> 
> 
> 
> Proposal B: Delete all these obsolete branches from the Apache git repo:
> 9/23/15 phase1 (72 behind master)
> 8/12/15 constraints (kensipe)
> 8/12/15 myriadha (kensipe)
> 8/10/15 issue_14 (smarella)
> 7/17/15 executor-only-application (kensipe)
> 6/11/15 multi-project (kensipe)
> 6/11/15 docker-image (kensipe)
> 3/04/15 issue_16 (mohit)
> If nobody speaks up to save any/all of these, I'll delete them next week.
> (Note that most of these still live on in the old github repo, if you look
> closely.)


 

Re: [PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[Todd Richmond]

excellent pro/con list

+1 for either A or + .5 for Alt 1. A branch is easy to follow and allows for 
long term patch support. Each new 0.x.y patch release becomes the only 
“supported” 0.x version but more than one “x” can be supported simultaneously

Alt 2 tags work best when you release very often (such as monthly) to users who 
are willing to upgrade and so can quickly deprecate previous releases. 
Cherry-picking is more manual effort and possibly error prone as the committer 
count grows

+1 for proposal B. feature branches can usually be done on private forks 
instead and should definitely be removed once the feature is merged to develop

  Todd


> On Dec 3, 2015, at 12:36 AM, Adam Bordelon  wrote:
> 
> Proposal A: Use Release Branches
> I propose that we create a '0.1.x' branch that will contain all of the
> 0.1.0-rc tags, the final 0.1.0 release tag, and any tags related to hotfix
> releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can cherry-pick
> fixes from master directly on top of the 0.1.0 tag in the 0.1.x branch, and
> we'll iterate on its rc's in the 0.1.x branch. Development for
> features/fixes for 0.2.0 go into the master branch, and whenever 0.2.0 is
> feature-complete/ready, we'll cut the new '0.2.x' branch from master and
> tag a 0.2.0-rc1, then cherry pick any necessary fixes from master into
> 0.2.x, for future release candidates and hotfix releases.
> + Easy to create/review github PRs to merge fixes into release candidates
> and hotfix releases.
> + Release candidates and hotfixes are handled in the appropriate release
> branch, while normal development can continue in master.
> + Minimal additional branches/commands required; no need for ephemeral
> branches for each release (candidate).
> 
> Alternative 1: Follow
> http://nvie.com/posts/a-successful-git-branching-model/#release-branches
> My proposal is similar to the model described by nvie except that we use
> the myriad 'master' branch for what he calls the 'develop' branch, and we
> use our 0.1.x,0.2.x release branches as longer-lived branches for hotfix
> releases. (Note: Feature branches are a separate discussion, unrelated to
> release management.)
> + Easy to follow guide.
> + Good separation of concerns/responsibility.
> - Doesn't explain how release candidates are handled.
> - So many branches.
> 
> Alternative 2: Use tags for releases, no branches (like Mesos does)
> See the discussion at:
> http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
> + No mess of branches in the repo; no merging between branches.
> + Since release candidates and releases are cherry-picked and tagged,
> normal development can continue on master without interruption/corruption.
> - Github PRs cannot use a tag (Dealbreaker?).
> http://stackoverflow.com/a/12279290/4056606
> 
> Please let me know your thoughts on release branches. I went ahead and
> created the '0.1.x' branch from the 0.1.0-rc3 tag so you can check it out
> and play around, and so you can push 0.2.0 features to master without
> worrying about messing up the 0.1.0 release. We can cherry-pick any
> rc4/0.1.1 patches out of master, and we can always delete/rename/reorg the
> release branch later if desired.
> https://git-wip-us.apache.org/repos/asf?p=incubator-myriad.git;a=shortlog;h=refs/heads/0.1.x
> 
> 
> 
> Proposal B: Delete all these obsolete branches from the Apache git repo:
> 9/23/15 phase1 (72 behind master)
> 8/12/15 constraints (kensipe)
> 8/12/15 myriadha (kensipe)
> 8/10/15 issue_14 (smarella)
> 7/17/15 executor-only-application (kensipe)
> 6/11/15 multi-project (kensipe)
> 6/11/15 docker-image (kensipe)
> 3/04/15 issue_16 (mohit)
> If nobody speaks up to save any/all of these, I'll delete them next week.
> (Note that most of these still live on in the old github repo, if you look
> closely.)

Re: Myriad's website is live!

[Brandon Gulla]

Great job!

On Thu, Dec 3, 2015 at 7:17 AM, Jim Klucar  wrote:

> Awesome. Hopefully we can push a post about the release soon!
>
> On Wed, Dec 2, 2015 at 10:14 PM, Sarjeet Singh 
> wrote:
>
> > Good one, Mohit. Kudos to make it work, and Others for contributing to
> > build the website!!
> >
> > Website looks great, and it has all necessary information to get it going
> > from here. Navigated around the website and it feels nice :)
> >
> > -Sarjeet
> >
> > On Wed, Dec 2, 2015 at 7:00 PM, mohit soni 
> > wrote:
> >
> > > Apache Myriad website is finally live, please go and checkout it out
> for
> > > real here !
> > >
> > > I was able to identify the root cause which was preventing jekyll from
> > > building the content correctly. Apparently, Jekyll does not like the
> > > comments place on top of the Liquid templates, for that matter it
> doesn't
> > > like anything (even newlines) before the triple dashes '' section.
> > Once
> > > I moved the triple dash section on top of the files, the rendering
> > started
> > > working just fine.
> > >
> > > Cheers!
> > > Mohit
> > >
> >
>



-- 
Brandon

Re: Myriad's website is live!

[Jim Klucar]

Awesome. Hopefully we can push a post about the release soon!

On Wed, Dec 2, 2015 at 10:14 PM, Sarjeet Singh 
wrote:

> Good one, Mohit. Kudos to make it work, and Others for contributing to
> build the website!!
>
> Website looks great, and it has all necessary information to get it going
> from here. Navigated around the website and it feels nice :)
>
> -Sarjeet
>
> On Wed, Dec 2, 2015 at 7:00 PM, mohit soni 
> wrote:
>
> > Apache Myriad website is finally live, please go and checkout it out for
> > real here !
> >
> > I was able to identify the root cause which was preventing jekyll from
> > building the content correctly. Apparently, Jekyll does not like the
> > comments place on top of the Liquid templates, for that matter it doesn't
> > like anything (even newlines) before the triple dashes '' section.
> Once
> > I moved the triple dash section on top of the files, the rendering
> started
> > working just fine.
> >
> > Cheers!
> > Mohit
> >
>

Re: [VOTE] Release Apache Myriad 0.1.0 (incubating)

[Santosh Marella]

Hello All,

  Just a reminder that this vote is still open.

 We've received feedback, and a binding +1, from just one IPMC member
(Justin Mclean). Appreciate if more folks can try out the RC and vote.

Thanks,
Santosh

On Mon, Nov 30, 2015 at 7:59 PM, Santosh Marella 
wrote:

> Thanks Justin. Appreciate your feedback.
>
> > You may want to also double check the version of bootstrap you have
> bundled, the comment says 3.2 and that it is Apache licensed, however
> > github shows 3.2 is MIT licensed. [1] I think the change from Apache to
> MIT happened at around 3.0.3. [2] If this is the case can you add bootstrap
> > to the LICENSE file in the next release. However it may be that Twitter
> didn’t update the header of this file. If that's the case I’d just leave it
> as it is.
>
> The bootstrap css bundled with Myriad was generated using
> http://bootswatchr.com/ by selecting version "3.2" of bootstrap.  I
> suspect bootswatchr is not including the right license header.
>
> /*!
>  * Bootstrap v3.2
>  *
>  * Copyright 2014 Twitter, Inc
>  * Licensed under the Apache License v2.0
>  * http://www.apache.org/licenses/LICENSE-2.0
>  *
>  * Designed and built with all the love in the world by @mdo and @fat.
>  * BootSwatchr built and provided by @DrewStrickland
>  */
> /*! normalize.css v3.0.1 | MIT License | git.io/normalize */
>
> Created https://issues.apache.org/jira/browse/MYRIAD-177 to fix this for
> the next release.
>
> Thanks,
> Santosh
>
> On Mon, Nov 30, 2015 at 5:47 PM, Justin Mclean 
> wrote:
>
>> Hi,
>>
>> +1 binding.
>>
>> I checked:
>> - release name contains incubating
>> - signature and hash good
>> - DISCLAIMER exists
>> - LICENSE and NOTICE good. May be minor LICENSE issue re bootstrap (see
>> below).
>> - no unexpected binary files
>> - all source files have Apache headers
>> - can compile from source
>>
>> You might want to in the next release sign the release with an apache
>> email address.
>>
>> You may want to also double check the version of bootstrap you have
>> bundled, the comment says 3.2 and that it is Apache licensed, however
>> github shows 3.2 is MIT licensed. [1] I think the change from Apache to MIT
>> happened at around 3.0.3. [2] If this is the case can you add bootstrap to
>> the LICENSE file in the next release. However it may be that Twitter didn’t
>> update the header of this file. If that's the case I’d just leave it as it
>> is. Sorry I missed this last time.
>>
>> I also had to increase the memory in gradle.properties to get the project
>> to compile without an out of heap space error but that may just be my setup.
>>
>> Thanks,
>> Justin
>>
>> 1. https://github.com/twbs/bootstrap/tree/v3.2.0 <
>> https://github.com/twbs/bootstrap/tree/v3.2.0>
>> 2. https://github.com/twbs/bootstrap/tree/v3.0.3 <
>> https://github.com/twbs/bootstrap/tree/v3.0.3>
>>
>>
>

[PROPOSAL(s)] Use Release Branches, and Delete Obsolete Branches

[Adam Bordelon]

Proposal A: Use Release Branches
I propose that we create a '0.1.x' branch that will contain all of the
0.1.0-rc tags, the final 0.1.0 release tag, and any tags related to hotfix
releases on top (0.1.1, 0.1.2). A hotfix release like 0.1.1 can cherry-pick
fixes from master directly on top of the 0.1.0 tag in the 0.1.x branch, and
we'll iterate on its rc's in the 0.1.x branch. Development for
features/fixes for 0.2.0 go into the master branch, and whenever 0.2.0 is
feature-complete/ready, we'll cut the new '0.2.x' branch from master and
tag a 0.2.0-rc1, then cherry pick any necessary fixes from master into
0.2.x, for future release candidates and hotfix releases.
+ Easy to create/review github PRs to merge fixes into release candidates
and hotfix releases.
+ Release candidates and hotfixes are handled in the appropriate release
branch, while normal development can continue in master.
+ Minimal additional branches/commands required; no need for ephemeral
branches for each release (candidate).

Alternative 1: Follow
http://nvie.com/posts/a-successful-git-branching-model/#release-branches
My proposal is similar to the model described by nvie except that we use
the myriad 'master' branch for what he calls the 'develop' branch, and we
use our 0.1.x,0.2.x release branches as longer-lived branches for hotfix
releases. (Note: Feature branches are a separate discussion, unrelated to
release management.)
+ Easy to follow guide.
+ Good separation of concerns/responsibility.
- Doesn't explain how release candidates are handled.
- So many branches.

Alternative 2: Use tags for releases, no branches (like Mesos does)
See the discussion at:
http://stackoverflow.com/questions/9810050/git-tag-vs-release-beta-branches
+ No mess of branches in the repo; no merging between branches.
+ Since release candidates and releases are cherry-picked and tagged,
normal development can continue on master without interruption/corruption.
- Github PRs cannot use a tag (Dealbreaker?).
http://stackoverflow.com/a/12279290/4056606

Please let me know your thoughts on release branches. I went ahead and
created the '0.1.x' branch from the 0.1.0-rc3 tag so you can check it out
and play around, and so you can push 0.2.0 features to master without
worrying about messing up the 0.1.0 release. We can cherry-pick any
rc4/0.1.1 patches out of master, and we can always delete/rename/reorg the
release branch later if desired.
https://git-wip-us.apache.org/repos/asf?p=incubator-myriad.git;a=shortlog;h=refs/heads/0.1.x



Proposal B: Delete all these obsolete branches from the Apache git repo:
9/23/15 phase1 (72 behind master)
8/12/15 constraints (kensipe)
8/12/15 myriadha (kensipe)
8/10/15 issue_14 (smarella)
7/17/15 executor-only-application (kensipe)
6/11/15 multi-project (kensipe)
6/11/15 docker-image (kensipe)
3/04/15 issue_16 (mohit)
If nobody speaks up to save any/all of these, I'll delete them next week.
(Note that most of these still live on in the old github repo, if you look
closely.)