Re: [boost] Request for comments on super-project workflow doc

Subject: Re: [boost] Request for comments on super-project workflow doc
From: Peter A. Bigot (pab_at_[hidden])
Date: 2014-01-02 16:30:05

On 01/02/2014 02:58 PM, Peter Dimov wrote:
> Peter A. Bigot wrote:
>> * Branch "latest": automatically tracks "develop" of submodules 
>> (scripted).
> ...
>> Does anybody have a use case for this?
>
> Yes.
>
> This branch is the equivalent of the old SVN trunk. It enables testing 
> of the develop branches of the submodules. The typical Boost developer 
> workflow is:
>
> - make changes
> - run local tests
> - when those pass, commit to develop (SVN trunk)
> - wait a few days for the develop (SVN trunk) testers to cycle
> - when those pass, merge to master (SVN release)
>
> In addition, testing a composition of the develop branches of the 
> submodules enables people to detect inadvertent breaking changes in a 
> dependent submodule and complain loudly. This ideally happens before 
> the merge to master. (Or, alternatively, if the changes were in fact 
> deliberate, it enables them to fix their code ahead of the merge to 
> master.)

Ack.  FWIW, that's not how I see submodule-based git projects in the 
general case.  If most Boost modules are independent (are they?), this 
process appears to introduce unnecessary coupling, rather like testing a 
bunch of unrelated feature branches together instead of validating and 
merging them one at a time as their individual developers feel they're 
ready.

I suspect that separate curated develop and auto-updated latest/master 
(latest/develop) would be more robust.  E.g. that approach reduces the 
risk of refactoring the assert library: neither module would appear in 
the stable branch (develop, in my proposal) until a release manager 
confirms they're compatible, preventing the churn from impacting people 
who don't care where the capability is placed.

But as long as everybody who maintains a Boost module is clear on the 
expectations and process, the assumptions of non-Boost people aren't 
particularly relevant.

>> Boost imposes no stability requirements on submodule develop 
>> branches, let alone interoperability requirements.
>
> That's not - quite - true. The develop branches are expected to work, 
> even though this is not strictly enforced. We mostly rely on the honor 
> system. :-)
>

OK.  Somebody should update 
https://svn.boost.org/trac/boost/wiki/StartModWorkflow?version=9#Branchnames 
then, since no stability expectation is mentioned.  In its current form, 
I would expect to feel free to initiate a long-term refactoring on my 
develop branch with no plans to push to master or maintain compatibility 
with other modules for several super-project release cycles, a process 
more consistent with my expectations of what the module master and 
develop branches mean under git-flow.

Peter