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