Am 11.04.25 um 01:29 schrieb Robert Ramey via Boost:
It's mostly a problem because I only engage in library maintenance occasionally. And truth is I forget a lot of stuff in the meantime. I'm also not a git guru (and hardly a git hacker!) which also means an amount of wasted time.
I do think we would be better served by shifting more to the feature branch way of doing things. Once one does this, the develop branch become superfluous.
Does "feature branch way of doing things" refer to: Develop a new feature in a branch, if done and tested merge that to "production"? I see how this makes the develop branch pretty much superfluous. It is the equivalent to a "staging" branch though, i.e. the last point before it goes to production. As you already test your changes against master and your CI tests them against develop when you open your usual PR what you could do is merge develop to master right after merging the PR. Of course except during a release preparation where the last merge needs to wait. This way your workflow has only a minor extra step but enables everyone else to maintain their workflow. As a "bonus" you can continue to work even when master is closed which you couldn't with only one branch. At least you could not test multiple changes/PRs together. To me it looks mainly like a communication issue: You look at your master branch after a while and see a non-merge commit you didn't do and were not aware of. Now you'd need to do extra work to check that this commit is also in your develop branch, which is annoying I guess. Would a compromise be acceptable for you that some "trusted contributors" (it seems only Peter does such cherry-picks) be allowed to merge develop to master when you didn't do that yet after merging a PR to develop? As your workflow of testing against master is known, I think there is no risk in doing that instead of cherry-picks. This way others are unblocked in case of "pending" changes from your side and you don't need to check anything extra if there are only merge commits in master. Of course this doesn't solve the issue where your develop branch gets broken due to a change in some other library. But that would soon be in master too breaking also your master branch. This is however not much different than when using a single-branch Boost-wide. That being said I understand your concern about having 2 branches, especially with the many states the whole of Boost could be in when each library can have "pending" changes or not. I've been bitten too waiting for changes that others didn't merge to master yet, but of course others are limited in their resources too. Maybe we can improve that somehow.