[PROPOSAL] 1.7/2.0 branches and git workflow change

[Christopher <ct...@apache.org>]

Okay, so when we first switched to git, Josh argued that the master branch
should be pristine... it should reflect the most recently released version.
We have not been doing that. Instead, we've been treating it as the main
development branch, following SVN conventions and treating it like trunk,
constantly merging to it whenever we apply a fix/update to an earlier
maintenance branch.

I've been thinking about creating a 2.0 branch to work in to do stuff that
we are planning to do for 2.0 that we have not yet committed to any branch
(like drop deprecated code and drop support for Hadoop 1). I'm hesitant to
do so if this branch will become yet another branch to merge through to
master, especially if this ultimately isn't the branch that becomes 2.0.0
release (for whatever reason).

Constantly moving master significantly reduces our ability to decide which
things to include in the next release (because they are essentially already
included, unless we revert, which can complicate things).

So, what I'd like to do is branch master as "1.7", and immediately stop
commits to "master". This gives us time to all get used to the new
workflow, while continuing to work towards 1.7.0.
When 1.7.0 is released, I'd like to merge it onto "master" and leave it
that way (pristine and identical to the 1.7.0 tag). This merge will be a
fast-forward merge, because nobody should have been committing anything to
master. If somebody makes a mistake and merges something to master, we have
time to correct them before the 1.7.0 release, and if somebody makes a
mistake after 1.7.0 is released and master is sync'd to it, we have other
emergency recourse (reset / force push or, more likely, revert master /
cherry-pick onto correct branch).

There may be other benefits to this, but the main thing I'm interested in
is greater control over what is included in a release, and long-term
planning branches for planned future versions (like 2.0) that are not the
immediate next release (like it appears 1.7.0 will be).

Thoughts? Questions? Comments? Objections?

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[David Medinets <da...@gmail.com>]

+1 for whatever option means master is the latest stable version
(i.e., production-ready).

On Tue, Oct 7, 2014 at 6:27 AM, William Slacum
<wi...@accumulo.net> wrote:
> Slight correction: "N patches" should be "N branches".
>
> On Tue, Oct 7, 2014 at 6:24 AM, William Slacum <
> wilhelm.von.cloud@accumulo.net> wrote:
>
>> #1 would be nice. I would discourage the cherry-pick-back-from-master
>> model because it completely disregards git's history model and makes
>> auditing changes nearly impossible because for N patches, the same change
>> exists N times under different IDs. If we wanted that, we'd be back to
>> subversion without mergeinfo.
>>
>> #2 and #3 is possible now with our branching strategy. Is there some
>> deficiency you notice with it?
>>
>> While we're a big project, I think we might be able to benefit from a
>> review-then-commit process. It could allow us to review any patch to
>> master, and if we determine it is relevant in historical branches, we
>> commit it to the historical branch and then merge forward before publishing
>> to our public history.
>>
>>
>>
>> On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bu...@cloudera.com> wrote:
>>
>>> What if we start with what we want and work from there, instead of
>>> starting
>>> from our current model.
>>>
>>> I would really like:
>>>
>>> 1) A *single* place where new contributors can base patches
>>>
>>> 2) Stable planned release lines where a release manager can determine what
>>> does or does not get included
>>>
>>> 3) a git history that makes it easy for me to tell what jiras impact a
>>> given release tag
>>>
>>> One way to achieve these goals is to adopt a commit-to-master and
>>> cherry-pick approach.
>>>
>>> * Master would be the default landing zone for new commits (unless they
>>> only apply to an older branch).
>>> * Master would have a version that represents unstable "future work" (so
>>> right now presumably 3.0 if Christopher wants to start solidifying 2.0)
>>> * We'd have a branch for each current dev branches
>>> * When a fix applies to an older branch a committer (and usually not a
>>> contributor) would cherry pick it from master
>>> * When the release manager for a new version was ready to start
>>> stabilizing
>>> things they'd make a new branch
>>> * Said release manager would determine what feature changes in master get
>>> pulled back to the new major release
>>>
>>> The big disadvantage with this approach is that in the event that there is
>>> a bad commit `git bisect` will only find it on a single development
>>> branch.
>>> On the plus side, the lack of merge commits means that it's easier to
>>> revert.
>>>
>>> On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ct...@apache.org> wrote:
>>>
>>> > True. Everything I'm thinking of would work with no master, but that
>>> might
>>> > be confusing, and might break some tooling without extra effort (which
>>> > branch is default when cloning?). We also kind of assume that the master
>>> > branch is forward-moving only, but other branches are disposable and
>>> can be
>>> > rebase'd, deleted, re-created, etc.
>>> >
>>> > Alternatively, if people understood that a "2.0" branch is a "future"
>>> > branch when 1.7 (master) is the "current", that'd work, too... I just
>>> worry
>>> > that people will merge it poorly.
>>> >
>>> > I suppose the best option, then, is probably to keep the status quo, and
>>> > use a branch name like "ACCUMULO-####" which represents the overall work
>>> > for a particular future release plan, instead of a name which looks
>>> like a
>>> > maintenance branch.
>>> >
>>> >
>>> > --
>>> > Christopher L Tubbs II
>>> > http://gravatar.com/ctubbsii
>>> >
>>> > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
>>> > wilhelm.von.cloud@accumulo.net> wrote:
>>> >
>>> > > It seems to me you can get everything you want by merely getting rid
>>> of
>>> > > master or making master just be the 1.7 branch. I'm not really
>>> concerned
>>> > > about the name, because it's easy enough to figure out. Master
>>> > duplicating
>>> > > a tag doesn't really seem useful to me, save for "here's the highest
>>> > > version we have released", which is of limited utility when a user can
>>> > just
>>> > > check the tags. I don't see the point in having master be something
>>> for
>>> > the
>>> > > sake of having master.
>>> > >
>>> > >
>>> > >
>>> > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com>
>>> wrote:
>>> > >
>>> > > > Christopher wrote:
>>> > > >
>>> > > >> What purpose does the master branch serve if it's just the same as
>>> the
>>> > > >>> last
>>> > > >>> >  major release tag?
>>> > > >>> >
>>> > > >>> >
>>> > > >>>
>>> > > >> I think Josh had some specific opinions on this, but the general
>>> idea
>>> > > from
>>> > > >> what I understood was that master is supposed to be stable...
>>> > > >> representative of the latest, most modern release, because it's
>>> what a
>>> > > new
>>> > > >> contributor would expect to fork to create a patch. That's hard to
>>> do
>>> > if
>>> > > >> the goalpost is moving a lot, and it makes feature merges more
>>> > > >> complicated,
>>> > > >> since contributors have to rebase or merge themselves in order to
>>> > > create a
>>> > > >> patch that merges cleanly. Having a stable master makes it very
>>> easy
>>> > to
>>> > > >> contribute to the most recent release.
>>> > > >>
>>> > > >
>>> > > > No, I don't really care for a stable-only master (I think I diverge
>>> > from
>>> > > > the git-flow model in that regard). I like master to just be a
>>> > > > "commits-go-here" area more than anything.
>>> > > >
>>> > >
>>> >
>>>
>>>
>>>
>>> --
>>> Sean
>>>
>>
>>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[William Slacum <wi...@accumulo.net>]

Slight correction: "N patches" should be "N branches".

On Tue, Oct 7, 2014 at 6:24 AM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

> #1 would be nice. I would discourage the cherry-pick-back-from-master
> model because it completely disregards git's history model and makes
> auditing changes nearly impossible because for N patches, the same change
> exists N times under different IDs. If we wanted that, we'd be back to
> subversion without mergeinfo.
>
> #2 and #3 is possible now with our branching strategy. Is there some
> deficiency you notice with it?
>
> While we're a big project, I think we might be able to benefit from a
> review-then-commit process. It could allow us to review any patch to
> master, and if we determine it is relevant in historical branches, we
> commit it to the historical branch and then merge forward before publishing
> to our public history.
>
>
>
> On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
>> What if we start with what we want and work from there, instead of
>> starting
>> from our current model.
>>
>> I would really like:
>>
>> 1) A *single* place where new contributors can base patches
>>
>> 2) Stable planned release lines where a release manager can determine what
>> does or does not get included
>>
>> 3) a git history that makes it easy for me to tell what jiras impact a
>> given release tag
>>
>> One way to achieve these goals is to adopt a commit-to-master and
>> cherry-pick approach.
>>
>> * Master would be the default landing zone for new commits (unless they
>> only apply to an older branch).
>> * Master would have a version that represents unstable "future work" (so
>> right now presumably 3.0 if Christopher wants to start solidifying 2.0)
>> * We'd have a branch for each current dev branches
>> * When a fix applies to an older branch a committer (and usually not a
>> contributor) would cherry pick it from master
>> * When the release manager for a new version was ready to start
>> stabilizing
>> things they'd make a new branch
>> * Said release manager would determine what feature changes in master get
>> pulled back to the new major release
>>
>> The big disadvantage with this approach is that in the event that there is
>> a bad commit `git bisect` will only find it on a single development
>> branch.
>> On the plus side, the lack of merge commits means that it's easier to
>> revert.
>>
>> On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ct...@apache.org> wrote:
>>
>> > True. Everything I'm thinking of would work with no master, but that
>> might
>> > be confusing, and might break some tooling without extra effort (which
>> > branch is default when cloning?). We also kind of assume that the master
>> > branch is forward-moving only, but other branches are disposable and
>> can be
>> > rebase'd, deleted, re-created, etc.
>> >
>> > Alternatively, if people understood that a "2.0" branch is a "future"
>> > branch when 1.7 (master) is the "current", that'd work, too... I just
>> worry
>> > that people will merge it poorly.
>> >
>> > I suppose the best option, then, is probably to keep the status quo, and
>> > use a branch name like "ACCUMULO-####" which represents the overall work
>> > for a particular future release plan, instead of a name which looks
>> like a
>> > maintenance branch.
>> >
>> >
>> > --
>> > Christopher L Tubbs II
>> > http://gravatar.com/ctubbsii
>> >
>> > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
>> > wilhelm.von.cloud@accumulo.net> wrote:
>> >
>> > > It seems to me you can get everything you want by merely getting rid
>> of
>> > > master or making master just be the 1.7 branch. I'm not really
>> concerned
>> > > about the name, because it's easy enough to figure out. Master
>> > duplicating
>> > > a tag doesn't really seem useful to me, save for "here's the highest
>> > > version we have released", which is of limited utility when a user can
>> > just
>> > > check the tags. I don't see the point in having master be something
>> for
>> > the
>> > > sake of having master.
>> > >
>> > >
>> > >
>> > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com>
>> wrote:
>> > >
>> > > > Christopher wrote:
>> > > >
>> > > >> What purpose does the master branch serve if it's just the same as
>> the
>> > > >>> last
>> > > >>> >  major release tag?
>> > > >>> >
>> > > >>> >
>> > > >>>
>> > > >> I think Josh had some specific opinions on this, but the general
>> idea
>> > > from
>> > > >> what I understood was that master is supposed to be stable...
>> > > >> representative of the latest, most modern release, because it's
>> what a
>> > > new
>> > > >> contributor would expect to fork to create a patch. That's hard to
>> do
>> > if
>> > > >> the goalpost is moving a lot, and it makes feature merges more
>> > > >> complicated,
>> > > >> since contributors have to rebase or merge themselves in order to
>> > > create a
>> > > >> patch that merges cleanly. Having a stable master makes it very
>> easy
>> > to
>> > > >> contribute to the most recent release.
>> > > >>
>> > > >
>> > > > No, I don't really care for a stable-only master (I think I diverge
>> > from
>> > > > the git-flow model in that regard). I like master to just be a
>> > > > "commits-go-here" area more than anything.
>> > > >
>> > >
>> >
>>
>>
>>
>> --
>> Sean
>>
>
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Sean Busbey <bu...@cloudera.com>]

On Tue, Oct 7, 2014 at 9:49 AM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

>
> I think Christopher's real issue (re: #2) is that it's ambiguous what
> bleeding-edge/trunk development should look like, because we don't have a
> defined goal. I proposed getting rid of master, or treating the 1.7 branch
> master, because we really don't know what 2.0 will look like yet. Divergent
> histories doesn't solve that.
>
>

I am a strong -1 on getting rid of master. Especially now that we are
talking about getting 1.7 out the door, we need a place that is for future
facing work so that 1.7 can start stabilizing. We will generally need a
place like this and it doesn't make sense to name it for a version e.g. if
we might end up with 1.8.



> As for tracking which issues are in a release, you do remove noise if you
> have a fix that only goes in a historical branch. That's about it, because
> it's still a function of good commit messages (which we're pretty awful at,
> if you subscribe to kernel-style commit message convention) to even infer
> which Jira issues are in some graph of history.
>

Even with just a jira id I can automate pulling the subject out of jira,
which we're generally better at setting to something useful. We have gotten
*loads* better at including a jira id (there were 2 missing in the last
month).



>
> Sean, you keep mentioning a release manager opting out-- how would that
> process go, in your mind? Would a release manger revert commits, or rewrite
> history to remove/delete commits? Could release managers for 2.0 and 1.7
> decide differently on whether or not they want to include a fix from 1.6?
>
>
In the commit-then-cherry-pick approach either the RM would give guidelines
for what they want included, give a sign-off on specific patches they want
included (on jira I guess?), or they could be responsible for all
cherry-picks to the branch depending on their temperament.

I suppose this could also be done in the merge-forward model, but it
results in even more complicated histories and/or a worsening of the "did
this jira actually impact this branch" issue.

And yes, the RMs could decide differently on if a fix had acceptable side
affects for their branch, which could lead to things like a bug being fixed
in 1.6.2  and master but not in 1.7.0. In practice we would deal with this
the way we mostly do now: through discussion, alternative solutions, and
release notes.

-- 
Sean

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[William Slacum <wi...@accumulo.net>]

Do we have a way to measure the efficacy of patches that exist in multiple
branches? By convention, each commit in an "early" branch will appear in
any later branch, so an existence check isn't sufficient, but it'd be cool
to see how much, on average, change a patch has to go through when being
merged forward.

But, on principal, I don't like the idea of divergent histories. Reverting
merges can be annoying, but we can also revert specific patches if need be.
Losing merge history is a big loss, and divergent history would mean we've
pushed auditing on change sets onto the developers-- we'd really be moving
backwards in terms of version control capabilities.

I think Christopher's real issue (re: #2) is that it's ambiguous what
bleeding-edge/trunk development should look like, because we don't have a
defined goal. I proposed getting rid of master, or treating the 1.7 branch
master, because we really don't know what 2.0 will look like yet. Divergent
histories doesn't solve that.

As for tracking which issues are in a release, you do remove noise if you
have a fix that only goes in a historical branch. That's about it, because
it's still a function of good commit messages (which we're pretty awful at,
if you subscribe to kernel-style commit message convention) to even infer
which Jira issues are in some graph of history.

Sean, you keep mentioning a release manager opting out-- how would that
process go, in your mind? Would a release manger revert commits, or rewrite
history to remove/delete commits? Could release managers for 2.0 and 1.7
decide differently on whether or not they want to include a fix from 1.6?

On Tue, Oct 7, 2014 at 10:17 AM, Keith Turner <ke...@deenlo.com> wrote:

> On Tue, Oct 7, 2014 at 6:24 AM, William Slacum <
> wilhelm.von.cloud@accumulo.net> wrote:
>
> > #1 would be nice. I would discourage the cherry-pick-back-from-master
> model
> > because it completely disregards git's history model and makes auditing
> > changes nearly impossible because for N patches, the same change exists N
> > times under different IDs. If we wanted that, we'd be back to subversion
> > without mergeinfo.
> >
> > #2 and #3 is possible now with our branching strategy. Is there some
> > deficiency you notice with it?
> >
> > While we're a big project, I think we might be able to benefit from a
> > review-then-commit process. It could allow us to review any patch to
> > master, and if we determine it is relevant in historical branches, we
> > commit it to the historical branch and then merge forward before
> publishing
> > to our public history.
> >
>
> We decided to try RTC on Fluo.  I love it.  We worked out a process using
> git and GH infrastructure that minimizes friction/overhead.  We are still
> refining the process and change it whenever something seems inefficient or
> isn't working well.  We are small team so we can be very agile in this
> regard.  We did not try define the process ahead of time and set in stone,
> rather we decided to experiment.  We started off with the simplest process
> possible and refined it as needed.
>
> The benefits I see are that I am more aware of other peoples work and
> together we are producing better quality code than anyone of us could
> alone.
>
> I may be wrong about this, but I feel with CTR there is no quid pro quo
> with reviews.  No one has to review to get their code commited :)
>
>
> >
> >
> >
> > On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bu...@cloudera.com> wrote:
> >
> > > What if we start with what we want and work from there, instead of
> > starting
> > > from our current model.
> > >
> > > I would really like:
> > >
> > > 1) A *single* place where new contributors can base patches
> > >
> > > 2) Stable planned release lines where a release manager can determine
> > what
> > > does or does not get included
> > >
> > > 3) a git history that makes it easy for me to tell what jiras impact a
> > > given release tag
> > >
> > > One way to achieve these goals is to adopt a commit-to-master and
> > > cherry-pick approach.
> > >
> > > * Master would be the default landing zone for new commits (unless they
> > > only apply to an older branch).
> > > * Master would have a version that represents unstable "future work"
> (so
> > > right now presumably 3.0 if Christopher wants to start solidifying 2.0)
> > > * We'd have a branch for each current dev branches
> > > * When a fix applies to an older branch a committer (and usually not a
> > > contributor) would cherry pick it from master
> > > * When the release manager for a new version was ready to start
> > stabilizing
> > > things they'd make a new branch
> > > * Said release manager would determine what feature changes in master
> get
> > > pulled back to the new major release
> > >
> > > The big disadvantage with this approach is that in the event that there
> > is
> > > a bad commit `git bisect` will only find it on a single development
> > branch.
> > > On the plus side, the lack of merge commits means that it's easier to
> > > revert.
> > >
> > > On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ct...@apache.org>
> > wrote:
> > >
> > > > True. Everything I'm thinking of would work with no master, but that
> > > might
> > > > be confusing, and might break some tooling without extra effort
> (which
> > > > branch is default when cloning?). We also kind of assume that the
> > master
> > > > branch is forward-moving only, but other branches are disposable and
> > can
> > > be
> > > > rebase'd, deleted, re-created, etc.
> > > >
> > > > Alternatively, if people understood that a "2.0" branch is a "future"
> > > > branch when 1.7 (master) is the "current", that'd work, too... I just
> > > worry
> > > > that people will merge it poorly.
> > > >
> > > > I suppose the best option, then, is probably to keep the status quo,
> > and
> > > > use a branch name like "ACCUMULO-####" which represents the overall
> > work
> > > > for a particular future release plan, instead of a name which looks
> > like
> > > a
> > > > maintenance branch.
> > > >
> > > >
> > > > --
> > > > Christopher L Tubbs II
> > > > http://gravatar.com/ctubbsii
> > > >
> > > > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
> > > > wilhelm.von.cloud@accumulo.net> wrote:
> > > >
> > > > > It seems to me you can get everything you want by merely getting
> rid
> > of
> > > > > master or making master just be the 1.7 branch. I'm not really
> > > concerned
> > > > > about the name, because it's easy enough to figure out. Master
> > > > duplicating
> > > > > a tag doesn't really seem useful to me, save for "here's the
> highest
> > > > > version we have released", which is of limited utility when a user
> > can
> > > > just
> > > > > check the tags. I don't see the point in having master be something
> > for
> > > > the
> > > > > sake of having master.
> > > > >
> > > > >
> > > > >
> > > > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Christopher wrote:
> > > > > >
> > > > > >> What purpose does the master branch serve if it's just the same
> as
> > > the
> > > > > >>> last
> > > > > >>> >  major release tag?
> > > > > >>> >
> > > > > >>> >
> > > > > >>>
> > > > > >> I think Josh had some specific opinions on this, but the general
> > > idea
> > > > > from
> > > > > >> what I understood was that master is supposed to be stable...
> > > > > >> representative of the latest, most modern release, because it's
> > > what a
> > > > > new
> > > > > >> contributor would expect to fork to create a patch. That's hard
> to
> > > do
> > > > if
> > > > > >> the goalpost is moving a lot, and it makes feature merges more
> > > > > >> complicated,
> > > > > >> since contributors have to rebase or merge themselves in order
> to
> > > > > create a
> > > > > >> patch that merges cleanly. Having a stable master makes it very
> > easy
> > > > to
> > > > > >> contribute to the most recent release.
> > > > > >>
> > > > > >
> > > > > > No, I don't really care for a stable-only master (I think I
> diverge
> > > > from
> > > > > > the git-flow model in that regard). I like master to just be a
> > > > > > "commits-go-here" area more than anything.
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Sean
> > >
> >
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Keith Turner <ke...@deenlo.com>]

On Tue, Oct 7, 2014 at 6:24 AM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

> #1 would be nice. I would discourage the cherry-pick-back-from-master model
> because it completely disregards git's history model and makes auditing
> changes nearly impossible because for N patches, the same change exists N
> times under different IDs. If we wanted that, we'd be back to subversion
> without mergeinfo.
>
> #2 and #3 is possible now with our branching strategy. Is there some
> deficiency you notice with it?
>
> While we're a big project, I think we might be able to benefit from a
> review-then-commit process. It could allow us to review any patch to
> master, and if we determine it is relevant in historical branches, we
> commit it to the historical branch and then merge forward before publishing
> to our public history.
>

We decided to try RTC on Fluo.  I love it.  We worked out a process using
git and GH infrastructure that minimizes friction/overhead.  We are still
refining the process and change it whenever something seems inefficient or
isn't working well.  We are small team so we can be very agile in this
regard.  We did not try define the process ahead of time and set in stone,
rather we decided to experiment.  We started off with the simplest process
possible and refined it as needed.

The benefits I see are that I am more aware of other peoples work and
together we are producing better quality code than anyone of us could
alone.

I may be wrong about this, but I feel with CTR there is no quid pro quo
with reviews.  No one has to review to get their code commited :)


>
>
>
> On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > What if we start with what we want and work from there, instead of
> starting
> > from our current model.
> >
> > I would really like:
> >
> > 1) A *single* place where new contributors can base patches
> >
> > 2) Stable planned release lines where a release manager can determine
> what
> > does or does not get included
> >
> > 3) a git history that makes it easy for me to tell what jiras impact a
> > given release tag
> >
> > One way to achieve these goals is to adopt a commit-to-master and
> > cherry-pick approach.
> >
> > * Master would be the default landing zone for new commits (unless they
> > only apply to an older branch).
> > * Master would have a version that represents unstable "future work" (so
> > right now presumably 3.0 if Christopher wants to start solidifying 2.0)
> > * We'd have a branch for each current dev branches
> > * When a fix applies to an older branch a committer (and usually not a
> > contributor) would cherry pick it from master
> > * When the release manager for a new version was ready to start
> stabilizing
> > things they'd make a new branch
> > * Said release manager would determine what feature changes in master get
> > pulled back to the new major release
> >
> > The big disadvantage with this approach is that in the event that there
> is
> > a bad commit `git bisect` will only find it on a single development
> branch.
> > On the plus side, the lack of merge commits means that it's easier to
> > revert.
> >
> > On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ct...@apache.org>
> wrote:
> >
> > > True. Everything I'm thinking of would work with no master, but that
> > might
> > > be confusing, and might break some tooling without extra effort (which
> > > branch is default when cloning?). We also kind of assume that the
> master
> > > branch is forward-moving only, but other branches are disposable and
> can
> > be
> > > rebase'd, deleted, re-created, etc.
> > >
> > > Alternatively, if people understood that a "2.0" branch is a "future"
> > > branch when 1.7 (master) is the "current", that'd work, too... I just
> > worry
> > > that people will merge it poorly.
> > >
> > > I suppose the best option, then, is probably to keep the status quo,
> and
> > > use a branch name like "ACCUMULO-####" which represents the overall
> work
> > > for a particular future release plan, instead of a name which looks
> like
> > a
> > > maintenance branch.
> > >
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
> > > wilhelm.von.cloud@accumulo.net> wrote:
> > >
> > > > It seems to me you can get everything you want by merely getting rid
> of
> > > > master or making master just be the 1.7 branch. I'm not really
> > concerned
> > > > about the name, because it's easy enough to figure out. Master
> > > duplicating
> > > > a tag doesn't really seem useful to me, save for "here's the highest
> > > > version we have released", which is of limited utility when a user
> can
> > > just
> > > > check the tags. I don't see the point in having master be something
> for
> > > the
> > > > sake of having master.
> > > >
> > > >
> > > >
> > > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com>
> > wrote:
> > > >
> > > > > Christopher wrote:
> > > > >
> > > > >> What purpose does the master branch serve if it's just the same as
> > the
> > > > >>> last
> > > > >>> >  major release tag?
> > > > >>> >
> > > > >>> >
> > > > >>>
> > > > >> I think Josh had some specific opinions on this, but the general
> > idea
> > > > from
> > > > >> what I understood was that master is supposed to be stable...
> > > > >> representative of the latest, most modern release, because it's
> > what a
> > > > new
> > > > >> contributor would expect to fork to create a patch. That's hard to
> > do
> > > if
> > > > >> the goalpost is moving a lot, and it makes feature merges more
> > > > >> complicated,
> > > > >> since contributors have to rebase or merge themselves in order to
> > > > create a
> > > > >> patch that merges cleanly. Having a stable master makes it very
> easy
> > > to
> > > > >> contribute to the most recent release.
> > > > >>
> > > > >
> > > > > No, I don't really care for a stable-only master (I think I diverge
> > > from
> > > > > the git-flow model in that regard). I like master to just be a
> > > > > "commits-go-here" area more than anything.
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Sean
> >
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Christopher <ct...@apache.org>]

On Tue, Oct 7, 2014 at 9:50 AM, Sean Busbey <bu...@cloudera.com> wrote:

> On Oct 7, 2014 5:25 AM, "William Slacum" <wi...@accumulo.net>
> wrote:
> >
> > #1 would be nice. I would discourage the cherry-pick-back-from-master
> model
> > because it completely disregards git's history model and makes auditing
> > changes nearly impossible because for N patches, the same change exists N
> > times under different IDs. If we wanted that, we'd be back to subversion
> > without mergeinfo.
> >
>
> That only happens for patches that apply to all branches, which hopefully
> soon means just bug fixes.
>
> We already effectively have patch-per-branch because our main dev lines
> have substantial differences. As it is now, those differences end up in
> merge commits where they're harder to deal with.
>
>
On the other hand, seeing that it was merged gives confidence (and a quick
way to test) that we won't regress.


> > #2 and #3 is possible now with our branching strategy. Is there some
> > deficiency you notice with it?
> >
>
> The main issue with #2 is the one Christopher brought up. Since we have to
> merge through each major version to get to master, there's no expectation
> that a release manager for e.g. 1.7 could opt out.
>
> For #3, I have to look at the results of a merge commit to know if the
> issue in an earlier release was also applicable to the newer branch or not.
>
> > While we're a big project, I think we might be able to benefit from a
> > review-then-commit process. It could allow us to review any patch to
> > master, and if we determine it is relevant in historical branches, we
> > commit it to the historical branch and then merge forward before
> publishing
> > to our public history.
> >
> >
>
> It's no secret that I would be thrilled if we switched to RtC. How would we
> deal with fixes that are substantively different on older branches?
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Sean Busbey <bu...@cloudera.com>]

On Oct 7, 2014 5:25 AM, "William Slacum" <wi...@accumulo.net>
wrote:
>
> #1 would be nice. I would discourage the cherry-pick-back-from-master
model
> because it completely disregards git's history model and makes auditing
> changes nearly impossible because for N patches, the same change exists N
> times under different IDs. If we wanted that, we'd be back to subversion
> without mergeinfo.
>

That only happens for patches that apply to all branches, which hopefully
soon means just bug fixes.

We already effectively have patch-per-branch because our main dev lines
have substantial differences. As it is now, those differences end up in
merge commits where they're harder to deal with.

> #2 and #3 is possible now with our branching strategy. Is there some
> deficiency you notice with it?
>

The main issue with #2 is the one Christopher brought up. Since we have to
merge through each major version to get to master, there's no expectation
that a release manager for e.g. 1.7 could opt out.

For #3, I have to look at the results of a merge commit to know if the
issue in an earlier release was also applicable to the newer branch or not.

> While we're a big project, I think we might be able to benefit from a
> review-then-commit process. It could allow us to review any patch to
> master, and if we determine it is relevant in historical branches, we
> commit it to the historical branch and then merge forward before
publishing
> to our public history.
>
>

It's no secret that I would be thrilled if we switched to RtC. How would we
deal with fixes that are substantively different on older branches?

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[William Slacum <wi...@accumulo.net>]

#1 would be nice. I would discourage the cherry-pick-back-from-master model
because it completely disregards git's history model and makes auditing
changes nearly impossible because for N patches, the same change exists N
times under different IDs. If we wanted that, we'd be back to subversion
without mergeinfo.

#2 and #3 is possible now with our branching strategy. Is there some
deficiency you notice with it?

While we're a big project, I think we might be able to benefit from a
review-then-commit process. It could allow us to review any patch to
master, and if we determine it is relevant in historical branches, we
commit it to the historical branch and then merge forward before publishing
to our public history.



On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bu...@cloudera.com> wrote:

> What if we start with what we want and work from there, instead of starting
> from our current model.
>
> I would really like:
>
> 1) A *single* place where new contributors can base patches
>
> 2) Stable planned release lines where a release manager can determine what
> does or does not get included
>
> 3) a git history that makes it easy for me to tell what jiras impact a
> given release tag
>
> One way to achieve these goals is to adopt a commit-to-master and
> cherry-pick approach.
>
> * Master would be the default landing zone for new commits (unless they
> only apply to an older branch).
> * Master would have a version that represents unstable "future work" (so
> right now presumably 3.0 if Christopher wants to start solidifying 2.0)
> * We'd have a branch for each current dev branches
> * When a fix applies to an older branch a committer (and usually not a
> contributor) would cherry pick it from master
> * When the release manager for a new version was ready to start stabilizing
> things they'd make a new branch
> * Said release manager would determine what feature changes in master get
> pulled back to the new major release
>
> The big disadvantage with this approach is that in the event that there is
> a bad commit `git bisect` will only find it on a single development branch.
> On the plus side, the lack of merge commits means that it's easier to
> revert.
>
> On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ct...@apache.org> wrote:
>
> > True. Everything I'm thinking of would work with no master, but that
> might
> > be confusing, and might break some tooling without extra effort (which
> > branch is default when cloning?). We also kind of assume that the master
> > branch is forward-moving only, but other branches are disposable and can
> be
> > rebase'd, deleted, re-created, etc.
> >
> > Alternatively, if people understood that a "2.0" branch is a "future"
> > branch when 1.7 (master) is the "current", that'd work, too... I just
> worry
> > that people will merge it poorly.
> >
> > I suppose the best option, then, is probably to keep the status quo, and
> > use a branch name like "ACCUMULO-####" which represents the overall work
> > for a particular future release plan, instead of a name which looks like
> a
> > maintenance branch.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
> > wilhelm.von.cloud@accumulo.net> wrote:
> >
> > > It seems to me you can get everything you want by merely getting rid of
> > > master or making master just be the 1.7 branch. I'm not really
> concerned
> > > about the name, because it's easy enough to figure out. Master
> > duplicating
> > > a tag doesn't really seem useful to me, save for "here's the highest
> > > version we have released", which is of limited utility when a user can
> > just
> > > check the tags. I don't see the point in having master be something for
> > the
> > > sake of having master.
> > >
> > >
> > >
> > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com>
> wrote:
> > >
> > > > Christopher wrote:
> > > >
> > > >> What purpose does the master branch serve if it's just the same as
> the
> > > >>> last
> > > >>> >  major release tag?
> > > >>> >
> > > >>> >
> > > >>>
> > > >> I think Josh had some specific opinions on this, but the general
> idea
> > > from
> > > >> what I understood was that master is supposed to be stable...
> > > >> representative of the latest, most modern release, because it's
> what a
> > > new
> > > >> contributor would expect to fork to create a patch. That's hard to
> do
> > if
> > > >> the goalpost is moving a lot, and it makes feature merges more
> > > >> complicated,
> > > >> since contributors have to rebase or merge themselves in order to
> > > create a
> > > >> patch that merges cleanly. Having a stable master makes it very easy
> > to
> > > >> contribute to the most recent release.
> > > >>
> > > >
> > > > No, I don't really care for a stable-only master (I think I diverge
> > from
> > > > the git-flow model in that regard). I like master to just be a
> > > > "commits-go-here" area more than anything.
> > > >
> > >
> >
>
>
>
> --
> Sean
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Christopher <ct...@apache.org>]

I think my proposal achieves #1 (patches are made against master), #2
(planned releases are constructed from rebase'd or merged topic branches
and bugfix merges from earlier maintenance branches), and #3 (this is
controllable a bit, because one can limit bugfix merges from earlier
branches when constructing a future release), but without the cherry-pick
approach which is problematic.

Creating a topic branch for a new release (which would best fit with the
status quo), one can do the same thing, but without #1.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey <bu...@cloudera.com> wrote:

> What if we start with what we want and work from there, instead of starting
> from our current model.
>
> I would really like:
>
> 1) A *single* place where new contributors can base patches
>
> 2) Stable planned release lines where a release manager can determine what
> does or does not get included
>
> 3) a git history that makes it easy for me to tell what jiras impact a
> given release tag
>
> One way to achieve these goals is to adopt a commit-to-master and
> cherry-pick approach.
>
> * Master would be the default landing zone for new commits (unless they
> only apply to an older branch).
> * Master would have a version that represents unstable "future work" (so
> right now presumably 3.0 if Christopher wants to start solidifying 2.0)
> * We'd have a branch for each current dev branches
> * When a fix applies to an older branch a committer (and usually not a
> contributor) would cherry pick it from master
> * When the release manager for a new version was ready to start stabilizing
> things they'd make a new branch
> * Said release manager would determine what feature changes in master get
> pulled back to the new major release
>
> The big disadvantage with this approach is that in the event that there is
> a bad commit `git bisect` will only find it on a single development branch.
> On the plus side, the lack of merge commits means that it's easier to
> revert.
>
> On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ct...@apache.org> wrote:
>
> > True. Everything I'm thinking of would work with no master, but that
> might
> > be confusing, and might break some tooling without extra effort (which
> > branch is default when cloning?). We also kind of assume that the master
> > branch is forward-moving only, but other branches are disposable and can
> be
> > rebase'd, deleted, re-created, etc.
> >
> > Alternatively, if people understood that a "2.0" branch is a "future"
> > branch when 1.7 (master) is the "current", that'd work, too... I just
> worry
> > that people will merge it poorly.
> >
> > I suppose the best option, then, is probably to keep the status quo, and
> > use a branch name like "ACCUMULO-####" which represents the overall work
> > for a particular future release plan, instead of a name which looks like
> a
> > maintenance branch.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
> > wilhelm.von.cloud@accumulo.net> wrote:
> >
> > > It seems to me you can get everything you want by merely getting rid of
> > > master or making master just be the 1.7 branch. I'm not really
> concerned
> > > about the name, because it's easy enough to figure out. Master
> > duplicating
> > > a tag doesn't really seem useful to me, save for "here's the highest
> > > version we have released", which is of limited utility when a user can
> > just
> > > check the tags. I don't see the point in having master be something for
> > the
> > > sake of having master.
> > >
> > >
> > >
> > > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com>
> wrote:
> > >
> > > > Christopher wrote:
> > > >
> > > >> What purpose does the master branch serve if it's just the same as
> the
> > > >>> last
> > > >>> >  major release tag?
> > > >>> >
> > > >>> >
> > > >>>
> > > >> I think Josh had some specific opinions on this, but the general
> idea
> > > from
> > > >> what I understood was that master is supposed to be stable...
> > > >> representative of the latest, most modern release, because it's
> what a
> > > new
> > > >> contributor would expect to fork to create a patch. That's hard to
> do
> > if
> > > >> the goalpost is moving a lot, and it makes feature merges more
> > > >> complicated,
> > > >> since contributors have to rebase or merge themselves in order to
> > > create a
> > > >> patch that merges cleanly. Having a stable master makes it very easy
> > to
> > > >> contribute to the most recent release.
> > > >>
> > > >
> > > > No, I don't really care for a stable-only master (I think I diverge
> > from
> > > > the git-flow model in that regard). I like master to just be a
> > > > "commits-go-here" area more than anything.
> > > >
> > >
> >
>
>
>
> --
> Sean
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Sean Busbey <bu...@cloudera.com>]

What if we start with what we want and work from there, instead of starting
from our current model.

I would really like:

1) A *single* place where new contributors can base patches

2) Stable planned release lines where a release manager can determine what
does or does not get included

3) a git history that makes it easy for me to tell what jiras impact a
given release tag

One way to achieve these goals is to adopt a commit-to-master and
cherry-pick approach.

* Master would be the default landing zone for new commits (unless they
only apply to an older branch).
* Master would have a version that represents unstable "future work" (so
right now presumably 3.0 if Christopher wants to start solidifying 2.0)
* We'd have a branch for each current dev branches
* When a fix applies to an older branch a committer (and usually not a
contributor) would cherry pick it from master
* When the release manager for a new version was ready to start stabilizing
things they'd make a new branch
* Said release manager would determine what feature changes in master get
pulled back to the new major release

The big disadvantage with this approach is that in the event that there is
a bad commit `git bisect` will only find it on a single development branch.
On the plus side, the lack of merge commits means that it's easier to
revert.

On Mon, Oct 6, 2014 at 10:41 PM, Christopher <ct...@apache.org> wrote:

> True. Everything I'm thinking of would work with no master, but that might
> be confusing, and might break some tooling without extra effort (which
> branch is default when cloning?). We also kind of assume that the master
> branch is forward-moving only, but other branches are disposable and can be
> rebase'd, deleted, re-created, etc.
>
> Alternatively, if people understood that a "2.0" branch is a "future"
> branch when 1.7 (master) is the "current", that'd work, too... I just worry
> that people will merge it poorly.
>
> I suppose the best option, then, is probably to keep the status quo, and
> use a branch name like "ACCUMULO-####" which represents the overall work
> for a particular future release plan, instead of a name which looks like a
> maintenance branch.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
> wilhelm.von.cloud@accumulo.net> wrote:
>
> > It seems to me you can get everything you want by merely getting rid of
> > master or making master just be the 1.7 branch. I'm not really concerned
> > about the name, because it's easy enough to figure out. Master
> duplicating
> > a tag doesn't really seem useful to me, save for "here's the highest
> > version we have released", which is of limited utility when a user can
> just
> > check the tags. I don't see the point in having master be something for
> the
> > sake of having master.
> >
> >
> >
> > On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> What purpose does the master branch serve if it's just the same as the
> > >>> last
> > >>> >  major release tag?
> > >>> >
> > >>> >
> > >>>
> > >> I think Josh had some specific opinions on this, but the general idea
> > from
> > >> what I understood was that master is supposed to be stable...
> > >> representative of the latest, most modern release, because it's what a
> > new
> > >> contributor would expect to fork to create a patch. That's hard to do
> if
> > >> the goalpost is moving a lot, and it makes feature merges more
> > >> complicated,
> > >> since contributors have to rebase or merge themselves in order to
> > create a
> > >> patch that merges cleanly. Having a stable master makes it very easy
> to
> > >> contribute to the most recent release.
> > >>
> > >
> > > No, I don't really care for a stable-only master (I think I diverge
> from
> > > the git-flow model in that regard). I like master to just be a
> > > "commits-go-here" area more than anything.
> > >
> >
>



-- 
Sean

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Christopher <ct...@apache.org>]

True. Everything I'm thinking of would work with no master, but that might
be confusing, and might break some tooling without extra effort (which
branch is default when cloning?). We also kind of assume that the master
branch is forward-moving only, but other branches are disposable and can be
rebase'd, deleted, re-created, etc.

Alternatively, if people understood that a "2.0" branch is a "future"
branch when 1.7 (master) is the "current", that'd work, too... I just worry
that people will merge it poorly.

I suppose the best option, then, is probably to keep the status quo, and
use a branch name like "ACCUMULO-####" which represents the overall work
for a particular future release plan, instead of a name which looks like a
maintenance branch.


--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

On Mon, Oct 6, 2014 at 10:59 PM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

> It seems to me you can get everything you want by merely getting rid of
> master or making master just be the 1.7 branch. I'm not really concerned
> about the name, because it's easy enough to figure out. Master duplicating
> a tag doesn't really seem useful to me, save for "here's the highest
> version we have released", which is of limited utility when a user can just
> check the tags. I don't see the point in having master be something for the
> sake of having master.
>
>
>
> On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Christopher wrote:
> >
> >> What purpose does the master branch serve if it's just the same as the
> >>> last
> >>> >  major release tag?
> >>> >
> >>> >
> >>>
> >> I think Josh had some specific opinions on this, but the general idea
> from
> >> what I understood was that master is supposed to be stable...
> >> representative of the latest, most modern release, because it's what a
> new
> >> contributor would expect to fork to create a patch. That's hard to do if
> >> the goalpost is moving a lot, and it makes feature merges more
> >> complicated,
> >> since contributors have to rebase or merge themselves in order to
> create a
> >> patch that merges cleanly. Having a stable master makes it very easy to
> >> contribute to the most recent release.
> >>
> >
> > No, I don't really care for a stable-only master (I think I diverge from
> > the git-flow model in that regard). I like master to just be a
> > "commits-go-here" area more than anything.
> >
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[William Slacum <wi...@accumulo.net>]

It seems to me you can get everything you want by merely getting rid of
master or making master just be the 1.7 branch. I'm not really concerned
about the name, because it's easy enough to figure out. Master duplicating
a tag doesn't really seem useful to me, save for "here's the highest
version we have released", which is of limited utility when a user can just
check the tags. I don't see the point in having master be something for the
sake of having master.



On Mon, Oct 6, 2014 at 9:19 PM, Josh Elser <jo...@gmail.com> wrote:

> Christopher wrote:
>
>> What purpose does the master branch serve if it's just the same as the
>>> last
>>> >  major release tag?
>>> >
>>> >
>>>
>> I think Josh had some specific opinions on this, but the general idea from
>> what I understood was that master is supposed to be stable...
>> representative of the latest, most modern release, because it's what a new
>> contributor would expect to fork to create a patch. That's hard to do if
>> the goalpost is moving a lot, and it makes feature merges more
>> complicated,
>> since contributors have to rebase or merge themselves in order to create a
>> patch that merges cleanly. Having a stable master makes it very easy to
>> contribute to the most recent release.
>>
>
> No, I don't really care for a stable-only master (I think I diverge from
> the git-flow model in that regard). I like master to just be a
> "commits-go-here" area more than anything.
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Josh Elser <jo...@gmail.com>]

Christopher wrote:
>> What purpose does the master branch serve if it's just the same as the last
>> >  major release tag?
>> >
>> >
> I think Josh had some specific opinions on this, but the general idea from
> what I understood was that master is supposed to be stable...
> representative of the latest, most modern release, because it's what a new
> contributor would expect to fork to create a patch. That's hard to do if
> the goalpost is moving a lot, and it makes feature merges more complicated,
> since contributors have to rebase or merge themselves in order to create a
> patch that merges cleanly. Having a stable master makes it very easy to
> contribute to the most recent release.

No, I don't really care for a stable-only master (I think I diverge from 
the git-flow model in that regard). I like master to just be a 
"commits-go-here" area more than anything.

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Christopher <ct...@apache.org>]

On Mon, Oct 6, 2014 at 8:07 PM, Sean Busbey <bu...@cloudera.com> wrote:

> Can you step through what you expect the workflow to be when fixing e.g. a
> bug against 1.5 using this model? Specifically after master is equivalent
> to the 1.7.0 tag.
>
>
The workflow is almost identical to before... just without the final merge
to master:

For a bug in 1.5, the patch is applied to the 1.5 branch, then merged to
1.6, then 1.7, but not to master. When 1.7.1 is released, master is updated
to 1.7.1.



> What purpose does the master branch serve if it's just the same as the last
> major release tag?
>
>
I think Josh had some specific opinions on this, but the general idea from
what I understood was that master is supposed to be stable...
representative of the latest, most modern release, because it's what a new
contributor would expect to fork to create a patch. That's hard to do if
the goalpost is moving a lot, and it makes feature merges more complicated,
since contributors have to rebase or merge themselves in order to create a
patch that merges cleanly. Having a stable master makes it very easy to
contribute to the most recent release.

But, this also gives us flexibility. If we automatically merge to master,
we're stuck with it and probably have to revert (which can get
complicated). However, if we're planning a 2.0 release, and we have
specific new features in 2.0, and it gets messed up in any way, we can
always cherry-pick or rebase what we want to keep onto a new 2.0 branch
from master, and merge any bugfixes that have occurred in the other
maintenance branches. The has good implications for release planning. It
also means we could avoid situations like constantly do a non-fastforward
merge because there was an early version name bump in the branch. We don't
have to be stuck with it.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii



> --
> Sean
> On Oct 6, 2014 6:18 PM, "Christopher" <ct...@apache.org> wrote:
>
> > Okay, so when we first switched to git, Josh argued that the master
> branch
> > should be pristine... it should reflect the most recently released
> version.
> > We have not been doing that. Instead, we've been treating it as the main
> > development branch, following SVN conventions and treating it like trunk,
> > constantly merging to it whenever we apply a fix/update to an earlier
> > maintenance branch.
> >
> > I've been thinking about creating a 2.0 branch to work in to do stuff
> that
> > we are planning to do for 2.0 that we have not yet committed to any
> branch
> > (like drop deprecated code and drop support for Hadoop 1). I'm hesitant
> to
> > do so if this branch will become yet another branch to merge through to
> > master, especially if this ultimately isn't the branch that becomes 2.0.0
> > release (for whatever reason).
> >
> > Constantly moving master significantly reduces our ability to decide
> which
> > things to include in the next release (because they are essentially
> already
> > included, unless we revert, which can complicate things).
> >
> > So, what I'd like to do is branch master as "1.7", and immediately stop
> > commits to "master". This gives us time to all get used to the new
> > workflow, while continuing to work towards 1.7.0.
> > When 1.7.0 is released, I'd like to merge it onto "master" and leave it
> > that way (pristine and identical to the 1.7.0 tag). This merge will be a
> > fast-forward merge, because nobody should have been committing anything
> to
> > master. If somebody makes a mistake and merges something to master, we
> have
> > time to correct them before the 1.7.0 release, and if somebody makes a
> > mistake after 1.7.0 is released and master is sync'd to it, we have other
> > emergency recourse (reset / force push or, more likely, revert master /
> > cherry-pick onto correct branch).
> >
> > There may be other benefits to this, but the main thing I'm interested in
> > is greater control over what is included in a release, and long-term
> > planning branches for planned future versions (like 2.0) that are not the
> > immediate next release (like it appears 1.7.0 will be).
> >
> > Thoughts? Questions? Comments? Objections?
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Christopher <ct...@apache.org>]

On Mon, Oct 6, 2014 at 8:38 PM, William Slacum <
wilhelm.von.cloud@accumulo.net> wrote:

> I'm confused. Merging through a branch that's not master to avoid merging
> through master doesn't really make anything less complicated. We still have
> to merge through to master any ways to have it be the latest stable
> release. All we have is another branch that has a more specific name.
>
>
Yes, but that merge to master will always be a FF merge, and it will leave
the master branch stable for contributors to create topic branches from
without moving their goalposts. And the more explicit name is a benefit,
I'd argue.



> Most of the theory behind what Josh wanted comes from this blog post:
> http://nvie.com/posts/a-successful-git-branching-model/ One of the
> disconnects between our branching strategy and the one it describes is that
> it doesn't really account for long term support branches. I don't think
> it's a good fit if we plan on supporting more than one release line.
>
>
Why not? If we're working towards faster bugfix releases, this model still
works well.


> There's no harm in branching a 2.0 branch that may or may not be merged in
> to master, or have other commits forwarded. Its existence has nothing to do
> with master until the time comes that we want its history to be accounted
> for in the master branch.
>

Well, no... that's what I'm proposing. If we create a 2.0 branch now, the
current workflow says merge to 2.0, then to master... that's what I'm
trying to avoid. But... we've got to leave master in *some* good state, and
this proposal gives us a reasonable state to stick to (for benefits named
above). What I'm trying to suggest is that we make "the time ... that we
want its history to be accounted for in the master branch" an action that
represents precisely such an explicit conscious decision. Right now, the
workflow says it's the next version so merge it, because we have no good
way of determining which version will be the next release.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii




>
> On Mon, Oct 6, 2014 at 8:07 PM, Sean Busbey <bu...@cloudera.com> wrote:
>
> > Can you step through what you expect the workflow to be when fixing e.g.
> a
> > bug against 1.5 using this model? Specifically after master is equivalent
> > to the 1.7.0 tag.
> >
> > What purpose does the master branch serve if it's just the same as the
> last
> > major release tag?
> >
> > --
> > Sean
> > On Oct 6, 2014 6:18 PM, "Christopher" <ct...@apache.org> wrote:
> >
> > > Okay, so when we first switched to git, Josh argued that the master
> > branch
> > > should be pristine... it should reflect the most recently released
> > version.
> > > We have not been doing that. Instead, we've been treating it as the
> main
> > > development branch, following SVN conventions and treating it like
> trunk,
> > > constantly merging to it whenever we apply a fix/update to an earlier
> > > maintenance branch.
> > >
> > > I've been thinking about creating a 2.0 branch to work in to do stuff
> > that
> > > we are planning to do for 2.0 that we have not yet committed to any
> > branch
> > > (like drop deprecated code and drop support for Hadoop 1). I'm hesitant
> > to
> > > do so if this branch will become yet another branch to merge through to
> > > master, especially if this ultimately isn't the branch that becomes
> 2.0.0
> > > release (for whatever reason).
> > >
> > > Constantly moving master significantly reduces our ability to decide
> > which
> > > things to include in the next release (because they are essentially
> > already
> > > included, unless we revert, which can complicate things).
> > >
> > > So, what I'd like to do is branch master as "1.7", and immediately stop
> > > commits to "master". This gives us time to all get used to the new
> > > workflow, while continuing to work towards 1.7.0.
> > > When 1.7.0 is released, I'd like to merge it onto "master" and leave it
> > > that way (pristine and identical to the 1.7.0 tag). This merge will be
> a
> > > fast-forward merge, because nobody should have been committing anything
> > to
> > > master. If somebody makes a mistake and merges something to master, we
> > have
> > > time to correct them before the 1.7.0 release, and if somebody makes a
> > > mistake after 1.7.0 is released and master is sync'd to it, we have
> other
> > > emergency recourse (reset / force push or, more likely, revert master /
> > > cherry-pick onto correct branch).
> > >
> > > There may be other benefits to this, but the main thing I'm interested
> in
> > > is greater control over what is included in a release, and long-term
> > > planning branches for planned future versions (like 2.0) that are not
> the
> > > immediate next release (like it appears 1.7.0 will be).
> > >
> > > Thoughts? Questions? Comments? Objections?
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> >
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[William Slacum <wi...@accumulo.net>]

I'm confused. Merging through a branch that's not master to avoid merging
through master doesn't really make anything less complicated. We still have
to merge through to master any ways to have it be the latest stable
release. All we have is another branch that has a more specific name.

Most of the theory behind what Josh wanted comes from this blog post:
http://nvie.com/posts/a-successful-git-branching-model/ One of the
disconnects between our branching strategy and the one it describes is that
it doesn't really account for long term support branches. I don't think
it's a good fit if we plan on supporting more than one release line.

There's no harm in branching a 2.0 branch that may or may not be merged in
to master, or have other commits forwarded. Its existence has nothing to do
with master until the time comes that we want its history to be accounted
for in the master branch.

On Mon, Oct 6, 2014 at 8:07 PM, Sean Busbey <bu...@cloudera.com> wrote:

> Can you step through what you expect the workflow to be when fixing e.g. a
> bug against 1.5 using this model? Specifically after master is equivalent
> to the 1.7.0 tag.
>
> What purpose does the master branch serve if it's just the same as the last
> major release tag?
>
> --
> Sean
> On Oct 6, 2014 6:18 PM, "Christopher" <ct...@apache.org> wrote:
>
> > Okay, so when we first switched to git, Josh argued that the master
> branch
> > should be pristine... it should reflect the most recently released
> version.
> > We have not been doing that. Instead, we've been treating it as the main
> > development branch, following SVN conventions and treating it like trunk,
> > constantly merging to it whenever we apply a fix/update to an earlier
> > maintenance branch.
> >
> > I've been thinking about creating a 2.0 branch to work in to do stuff
> that
> > we are planning to do for 2.0 that we have not yet committed to any
> branch
> > (like drop deprecated code and drop support for Hadoop 1). I'm hesitant
> to
> > do so if this branch will become yet another branch to merge through to
> > master, especially if this ultimately isn't the branch that becomes 2.0.0
> > release (for whatever reason).
> >
> > Constantly moving master significantly reduces our ability to decide
> which
> > things to include in the next release (because they are essentially
> already
> > included, unless we revert, which can complicate things).
> >
> > So, what I'd like to do is branch master as "1.7", and immediately stop
> > commits to "master". This gives us time to all get used to the new
> > workflow, while continuing to work towards 1.7.0.
> > When 1.7.0 is released, I'd like to merge it onto "master" and leave it
> > that way (pristine and identical to the 1.7.0 tag). This merge will be a
> > fast-forward merge, because nobody should have been committing anything
> to
> > master. If somebody makes a mistake and merges something to master, we
> have
> > time to correct them before the 1.7.0 release, and if somebody makes a
> > mistake after 1.7.0 is released and master is sync'd to it, we have other
> > emergency recourse (reset / force push or, more likely, revert master /
> > cherry-pick onto correct branch).
> >
> > There may be other benefits to this, but the main thing I'm interested in
> > is greater control over what is included in a release, and long-term
> > planning branches for planned future versions (like 2.0) that are not the
> > immediate next release (like it appears 1.7.0 will be).
> >
> > Thoughts? Questions? Comments? Objections?
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>

Re: [PROPOSAL] 1.7/2.0 branches and git workflow change

[Sean Busbey <bu...@cloudera.com>]

Can you step through what you expect the workflow to be when fixing e.g. a
bug against 1.5 using this model? Specifically after master is equivalent
to the 1.7.0 tag.

What purpose does the master branch serve if it's just the same as the last
major release tag?

-- 
Sean
On Oct 6, 2014 6:18 PM, "Christopher" <ct...@apache.org> wrote:

> Okay, so when we first switched to git, Josh argued that the master branch
> should be pristine... it should reflect the most recently released version.
> We have not been doing that. Instead, we've been treating it as the main
> development branch, following SVN conventions and treating it like trunk,
> constantly merging to it whenever we apply a fix/update to an earlier
> maintenance branch.
>
> I've been thinking about creating a 2.0 branch to work in to do stuff that
> we are planning to do for 2.0 that we have not yet committed to any branch
> (like drop deprecated code and drop support for Hadoop 1). I'm hesitant to
> do so if this branch will become yet another branch to merge through to
> master, especially if this ultimately isn't the branch that becomes 2.0.0
> release (for whatever reason).
>
> Constantly moving master significantly reduces our ability to decide which
> things to include in the next release (because they are essentially already
> included, unless we revert, which can complicate things).
>
> So, what I'd like to do is branch master as "1.7", and immediately stop
> commits to "master". This gives us time to all get used to the new
> workflow, while continuing to work towards 1.7.0.
> When 1.7.0 is released, I'd like to merge it onto "master" and leave it
> that way (pristine and identical to the 1.7.0 tag). This merge will be a
> fast-forward merge, because nobody should have been committing anything to
> master. If somebody makes a mistake and merges something to master, we have
> time to correct them before the 1.7.0 release, and if somebody makes a
> mistake after 1.7.0 is released and master is sync'd to it, we have other
> emergency recourse (reset / force push or, more likely, revert master /
> cherry-pick onto correct branch).
>
> There may be other benefits to this, but the main thing I'm interested in
> is greater control over what is included in a release, and long-term
> planning branches for planned future versions (like 2.0) that are not the
> immediate next release (like it appears 1.7.0 will be).
>
> Thoughts? Questions? Comments? Objections?
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>