accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [PROPOSAL] 1.7/2.0 branches and git workflow change
Date Tue, 07 Oct 2014 13:55:07 GMT
On Tue, Oct 7, 2014 at 9:50 AM, Sean Busbey <busbey@cloudera.com> wrote:

> On Oct 7, 2014 5:25 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.
> >
>
> 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.
>
>
On the other hand, seeing that it was merged gives confidence (and a quick
way to test) that we won't regress.


> > #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
> publishing
> > 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?
>

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