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  ... not sure if
>> this has any other side effects, but i'd vote for changing the default
>> to "develop".
>>  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
> 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.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk