Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAGHyZ6+iU7i1ZLXHWU5zGPdreyVHwXhbG8of7yDCa_pY8B0=iw@mail.gmail.com>
References: 
 <CAL5zq9bR02UDNRsBJzdMhuzzKPTXE_ctCxPBZ_rL_V9q3AUmYg@mail.gmail.com>
	<CAGHyZ6KX0mQapA2XB3HWLr=zDD3n0Zo-b0-v2U-apkoVEU4M8w@mail.gmail.com>
	<CAL5zq9YEd4PWg2dOpq9Eiuxe0SOq5EQcdAC6F=iy54VYFbCraQ@mail.gmail.com>
	<54333FB0.7060005@gmail.com>
	<CAMz+DuuYi7CDWZK30wWWyu5mM0AvywQ8kXjdCqMQQwuw7bp+ZQ@mail.gmail.com>
	<CAL5zq9ZNtNEDe9fnTAj5bk==oRptx4vLL=rNLOq5dw3b_L3K5g@mail.gmail.com>
	<CAGHyZ6+iU7i1ZLXHWU5zGPdreyVHwXhbG8of7yDCa_pY8B0=iw@mail.gmail.com>
Date: Tue, 7 Oct 2014 09:52:39 -0400
Message-ID: 
 <CAL5zq9Y9tFrnjk21ozs2KWm4f6dhP3R1gm=qH0ifMuZEi3mPSA@mail.gmail.com>
Subject: Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
From: Christopher <ctubbsii@apache.org>
To: Accumulo Dev List <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=f46d044287ee38c45d0504d58301

--f46d044287ee38c45d0504d58301
Content-Type: text/plain; charset=UTF-8

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 <busbey@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 <ctubbsii@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 <josh.elser@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
>

--f46d044287ee38c45d0504d58301--