On Tue, Oct 7, 2014 at 9:50 AM, Sean Busbey <bus...@cloudera.com> wrote:
> On Oct 7, 2014 5:25 AM, "William Slacum" <wilhelm.von.cl...@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? >
