accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Slacum <wilhelm.von.cl...@accumulo.net>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 10:27:38 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message