Re: [boost] [github] default PR destination

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] https://help.github.com/articles/setting-the-default-branch
>

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 
purpose?

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 
requests.

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.

Peter