From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2025-04-11 11:05:28
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.