Note (1): my depiction of the current Boost workflow might be inaccurate. If you see a way to improve the image, please go ahead or let me know what needs to be changed.
You've actually over-estimated our process. We never do a complete merge from trunk to release, just either cherry-pick changes, or do a sub-tree merge. There are often long neglected changes in trunk - which is a major problem with the current system.
Good to hear that at least I didn't under-estimate it. :-) I guess the difference between a merge with manual exceptions and cherry picking is only gradual, but I strongly agree neither is ideal.
Thanks for the effort, but what you proposed is a perfectly valid SVN workflow to me. There's nothing specific to git, besides the naming conventions of the branches, if I had to draw one for SVN the result would be the exact same with s/develop/trunk/ and s/master/tags/. On the other hand, whether we use git or SVN, I agree that the current model is not efficient. I think that trunk and release are redundant, it should be just trunk (this is not recommended just by me, see the wikipedia entry on continuous integration that I quoted earlier), with tags for releases. Since trunk is automatically tested, I see no reason to add an additional step before release that seemed to be completely neglected by developers. Removing that unecessary (IMHO) release branch may force people to pay more attention to what they are commiting and lower the load on the test system (which seems to be a problem) because there's no more release to test. Instead, a temporary release branch may be created from trunk and worked on directly when the beta is fixed. (And it seems to be that this is exactly what you proposed on your git schema) Julien