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.
from my understanding the svn policy was that changes *have* to go to trunk before they can be merged to the release branch. reason changes should not be merged to master(==release) before tests on develop(==trunk) have cycled. even if a contribution is based on "master" it should go to "develop" first. now if a contributor issues a PR to the master branch, the PR circumvents the testfarm, which imho is a bad thing and should definitely not be the default. all your arguments about checking the git history are fine, but simply don't apply in the case that master==release. tim