> Stable releases have been treated as an after-the-fact thing. I'm proposing > that we change that behavior.
I think being more strict about keeping one change / bug fix per commit and opening corresponding PRs for release branches with those commits right away would help. We could also open issues to track merging bug fixes to release branch but that could be extra overhead. Thanks, Arun. -----Original Message----- From: ofiwg [mailto:[email protected]] On Behalf Of Hefty, Sean Sent: Tuesday, November 28, 2017 10:55 AM To: Jeff Squyres (jsquyres) <[email protected]> Cc: OFIWG Mailing list <[email protected]> Subject: Re: [ofiwg] managing stable branches > 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. > Or, put differently: if this is *your* problem / individual developers > are not good about cherry picking their own commits down to release > branches, what's the chance that they'll think/remember to add > "TOKEN:RELEASE" to their commit messages for relevant commits? It's less work, so hopefully better than cherry-picking and opening multiple PRs. If I see a PR that looks like stable material, I usually ask the submitter to open a separate PR against the branch, or I'll mark it on github and hope I remember to pick it manually. Asking to update a commit message is easier on the submitter. How does OMPI handle backporting fixes to stable releases? - Sean _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg _______________________________________________ ofiwg mailing list [email protected] http://lists.openfabrics.org/mailman/listinfo/ofiwg
