[ofiwg] managing stable branches

[Jeff Squyres (jsquyres)]

On Nov 28, 2017, at 1:54 PM, Hefty, Sean <sean.hefty at intel.com> wrote:
> 
>> I hear what you're saying, but let me ask you a different question:
>> why is this *your* problem?
> 
> I'm usually the one responsible for creating the stable release, and I’m often the first person any problems are routed to.
> 
> Stable releases have been treated as an after-the-fact thing.  I'm proposing that we change that behavior.

That would be an important zeroth step, I think: change the dev mindset such that when the put in a bug fix on master, they also think about which release branch(es) that bug fix needs to go to.

> How does OMPI handle backporting fixes to stable releases?

Open MPI has a release train methodology.  We basically have 4 trains operating simultaneously:

1. master
2. next stable release (branched from master)
3. current stable release (branched from master a while ago)
4. previous stable release (branched from master a long time ago)

We basically support customers with versions from #3 and #4.  Libfabric doesn't use the #2 concept -- it does all of its staging on master (which is fine -- I'm not lobbying to change that).

When a dev commits a bug fix on master, it's the dev's responsibility to also make a PR for any relevant release branches (up to 3 -- which is a bit of a pain, but we chose this methodology cognizant of this consequence).  They can either make the PRs for the release branches immediately (which I usually do because otherwise I forget), or they can remember to make the release branch PRs later.

We also have a firm rule that nothing can be merged to a release branch unless it is already on master.  Hence, when we make an issue or a PR that is relevant to master, we put labels on it about which branches the PR also needs to be applied to (i.e., what future PRs need to be created against release branches).  E.g., labels named "Target: v2.1.x" or "Target: 3.1.x", ...etc.

This is why I asked: why is it *Sean's* problem to back port all the bug fixes.  *All developers* should do this, IMHO.  :-)  However, this can only be done if developers know what branches are still being maintained / will be released in the future, ...etc.  Hence, it means formalizing the release plans a bit.

Make sense?

-- 
Jeff Squyres
jsquyres at cisco.com