Boost logo

Boost :

Subject: Re: [boost] [github] default PR destination
From: Peter A. Bigot (pab_at_[hidden])
Date: 2014-01-05 09:21:11

On 01/04/2014 05:51 AM, Tim Blechmann wrote:
> hi all,
> any opinion to change the default branch from "master" to "develop"?
> with the boost branching model all contributions via github's pull
> requests apparently have to go to "develop" rather than going directly
> into "master", so this should be the default destination for pull
> requests. github allows to set the default branch [1] ... not sure if
> this has any other side effects, but i'd vote for changing the default
> to "develop".
> thoughts?
> tim
> [1]

tl;dr: leave it up to the individual module developer based on the
answer to this question: Who's submitting pull requests, and for what

FWIW, I have submitted four PRs to Boost in the past two weeks. One to
the superproject, one each in three modules. Two are trivial fixes to
showstopper bugs; one is a documentation fix relevant only to new
developers; and one aggregates fixes for a couple bugs (one showstopper)
and enhances functionality. All address issues visible in Boost 1.55.
So I think I'm representative of one class of people who will use pull

Here's my use case: I use open source, preferring package versions
supplied by the OS vendor (e.g. Ubuntu). When I need something more
recent, I install from a versioned release tarfile. When I discover
problems, I try to locate a git repository for the project and locate an
existing patch in a subsequent release or development branch. For my
local installation I branch off the commit corresponding to the release
I'm using, and either back-port the existing patch or fix the bug
myself. If there isn't already a solution, I open a bug report and
attach my patch to it; for github, that's creating an issue submitting a
pull request referencing it. I'm acting as a Boost user (not developer),
who is able to provide a proposed solution along with the problem report.

Now: Of the four pull requests I submitted, three were based off
develop, and one off master, but that's not representative because I
assumed develop was more stable and decoupled than it is. The last one
(regex) I did off master, and I expect that most future ones will also
be off master. Only when I'm acting as a Boost contributor (e.g. the
string_ref enhancements for utility) would I create a workspace that
checks out all the develop branches and make the extra effort to test
what I've done against that as opposed to the stable system for which I
need the change.

So most of my future pull requests will be based off tags on the master
branch. For modules that follow git-flow, those tags will reference
commits that are not on develop, so setting the default branch to
develop will create horrible "your branch is 350 commits ahead and 452
commits behind base" diagnostics.

If modules ultimately push to their master branch only when the
superproject releases, then master is the best default basis for pull
requests in my situation. If after things settle modules continue to
push to master multiple times throughout a release cycle, I'll always
have to reset the base to the release version, but they would still at
least be on the same branch as the default.

Switching to develop is not appropriate for my situation, which is
user-oriented. So move on to developer-oriented use cases:

I expect module developers will not be making pull requests for their
own modules, unless the module-level process imposes a strict
peer-review expectation. So there is no need to switch the default to
develop in support of the developers of that module.

It may be that developers of one module may wish to submit a change to
another, e.g. to resolve interoperability issues. If that happens,
develop is the correct base. I have no basis for a guess as to likelihood.

Finally, when you submit a pull request github clearly shows those 356
commits ahead and 452 commits behind, so if you understand enough about
git/github to fork, branch, and submit a pull request you probably can
figure out how to change the base so it's correct.

Summarizing: I see no need for a Boost-wide policy, and no need for
individual modules to change anything until there's experience
justifying the change.


Boost list run by bdawes at, gregod at, cpdaniel at, john at