accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 13:50:59 GMT
On Oct 7, 2014 5:25 AM, "William Slacum" <>
> #1 would be nice. I would discourage the cherry-pick-back-from-master
> 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.

That only happens for patches that apply to all branches, which hopefully
soon means just bug fixes.

We already effectively have patch-per-branch because our main dev lines
have substantial differences. As it is now, those differences end up in
merge commits where they're harder to deal with.

> #2 and #3 is possible now with our branching strategy. Is there some
> deficiency you notice with it?

The main issue with #2 is the one Christopher brought up. Since we have to
merge through each major version to get to master, there's no expectation
that a release manager for e.g. 1.7 could opt out.

For #3, I have to look at the results of a merge commit to know if the
issue in an earlier release was also applicable to the newer branch or not.

> 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
> to our public history.

It's no secret that I would be thrilled if we switched to RtC. How would we
deal with fixes that are substantively different on older branches?

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