Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 wilhelm.von.cloud@accumulo.net does not designate 209.85.212.177 as permitted
 sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGUtCHo_KHiYiQCfoSH9Va4f3vQ_XYGmWC1j9O=HgsTESGJbrA@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>
	<CAMz+Dus8os-vwMgom1HeUKW6q9Fm2qZPhm6kkVyzB+LvfKx_Rw@mail.gmail.com>
	<CAGUtCHo_KHiYiQCfoSH9Va4f3vQ_XYGmWC1j9O=HgsTESGJbrA@mail.gmail.com>
Date: Tue, 7 Oct 2014 10:49:23 -0400
Message-ID: 
 <CAMz+DusYm69XoWO3P8--jC4ojKxzesaCNcOXjaWcqqmDAyPkTg@mail.gmail.com>
Subject: Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
From: William Slacum <wilhelm.von.cloud@accumulo.net>
To: "dev@accumulo apache. org" <dev@accumulo.apache.org>
Content-Type: multipart/alternative; boundary=047d7bea40562112270504d64eb0

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

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 <keith@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 <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
> > >
> >
>

--047d7bea40562112270504d64eb0--