On Monday 09 December 2013 16:32:18 Peter Dimov wrote:
Andrey Semashev wrote:
I think it would be more productive to just fix the problem in develop and then in master of the submodule.
We're using different meanings of "fix" here. Imagine that the submodule has the following sequence of commits:
- bug fix - new feature - bug fix - more of new feature - bug fix
and the new feature turns out to block the Boost release. Fixing the problem, in your sense, means fixing the new feature so that it becomes Boost-release-worthy. This should indeed be done in develop. Fixing the problem, in my sense, means doing
- revert "more of new feature" - revert "new feature"
on a branch.
Sure, fixing the new feature is more productive. It's also a lot slower process over which the release managers have no control.
You can "revert" the feature by just changing the reference to the commit in the superproject release branch to an earlier commit, before the feature was added to the library master. Of course, it won't be that simple if other libraries rely on the added feature, and in this case it may be simpler to fix the feature instead of reverting. In both cases you don't need extra branches in the submodule. My main concern with these branches is that it's not clear what the library maintainers should do with them. If these fixes are considered valuable than why not do them in the normal way in the first place? After all, master is advertised as the releasable state of the library, not some personal branch of the release manager.