Re: [boost] A proposal for superproject structure and testing

Subject: Re: [boost] A proposal for superproject structure and testing
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-09 09:47:25

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.