accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 05:12:44 GMT
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