I hear what you are saying - we just beg to disagree :-) As Jeff said, a lot of it is history, but we’ve found this method works well for us and we’ve chosen to continue it.
> On Oct 17, 2014, at 7:35 AM, Jed Brown <j...@jedbrown.org> wrote: > > Ralph Castain <r...@open-mpi.org> writes: >> We go the other direction - all code must be committed to master so it >> can “soak” prior to moving to a release branch. > > Maybe we're miscommunicating. Normal lifecycle for a bug fix is > > # start from oldest maintenance branch to which the fix is relevant > git checkout -b jed/bug-fix maint > ... fix bug, commit, submit pull request, review, revise if needed > > # [optional] If using 'next' for eager users/testing prior to 'master' > git checkout next > git merge jed/bug-fix > ... "eager" users test this bug fix in combination with everything else > > # feature graduates to 'master' > git checkout master > git merge jed/bug-fix > ... users of 'master' interact with bug fix, bringing more confidence > > # feature merged to release/maintenance branch > git checkout maint > git merge jed/bug-fix > > > At the end of the day, there is only one commit effecting the change and > we can easily check who has it. If someone else needs the fix in their > development branch, they can get it without side-effects by merging > jed/bug-fix. The 'next' branch, which is entirely optional, helps > further stabilize 'master' - bugs in 'master' *disrupt other developers* > while bugs in 'next' only disrupt testing. Here's a diagram: > > > https://docs.google.com/drawings/d/1hvwyCIw4Wq3NoRrPpWfPTriJn5MM2_QkaacAaql8FQE/edit > > The "merging upward" is about > > git checkout master > git merge maint > git checkout next > git merge master > > These merges rarely contain non-merge commits (the topic branches were > already merged to 'next' and then 'master'); they just tie up the graph > so that subsequent merges only contain the "interesting" content. > > > If instead, your workflow has you committing a bug-fix on 'master', you > have to rebase/cherry-pick it to get it into a release branch without > side-effects. Now your repository has two commits that do the same > thing. A workflow should make it easy to get bug-fixes and features to > different audiences (e.g., release users versus developers) without > side-effects and without duplication. > >> The “upward” methodology works fine for stable situations where the >> master isn’t changing much relative to the releases, > > I disagree. There are many agile projects that merge upward using topic > branches, as described above.
