accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Turner <ke...@deenlo.com>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 14:17:04 GMT
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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message