accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Medinets <david.medin...@gmail.com>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 11:25:05 GMT
+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
<wilhelm.von.cloud@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 <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
View raw message