Re: [boost] [github] default PR destination

Subject: Re: [boost] [github] default PR destination
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-01-05 13:22:50

On 1/5/2014 9:21 AM, Peter A. Bigot wrote:
> 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.

Normally library developers will not merge changes from 'develop' to 
'master' until regression tests cycle through for a reasonable period of 
time ( normally about a week to a month ) showing that any changes made 
in 'develop' are working properly. The fact that a library has many 
changes made in 'develop' over a long period of time which has not been 
merged into 'master' does not change the general fact that this is not 
the way the vast majority of library developers work.