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 13:16:23

On 01/02/2014 10:19 AM, Beman Dawes wrote:
> The release managers with help from Peter Dimov have been developing
> super-project workflow documentation.
>
> See https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow
>
> Comments welcome!

A couple comments from an outsider who's done a lot of git and release 
process management, but is not deeply familiar with Boost history:

For branch semantics:

https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow#Namingrationale 
has:

* Branch "latest": automatically tracks "develop" of submodules (scripted).

I don't see a need for a branch with this tracking policy.  Boost 
imposes no stability requirements on submodule develop branches, let 
alone interoperability requirements.  The timeline for module 
development may not be targeting the next super-project release (e.g., 
Boost.Test has four years of changes in develop that have never seen a 
release).  Further, any remaining material in the super-project that 
depends on submodule content (e.g. testing) may break badly, making the 
branch unusable.

Does anybody have a use case for this?

* Branch "develop": automatically tracks "master" of submodules (scripted).

git-flow expects develop to be used to branch releases, but an automatic 
update policy makes it difficult to first reach a stable point with a 
curated set of submodule releases.  It also makes it hard to submit 
patches to any non-module content in the superproject (and I believe 
there will always be some such, if nothing more than metadata and 
generic documentation).

To address these issues I propose the following changes:

* Branch "latest": Merges from super-project "develop" and tracks 
"master" of submodules (scripted).

By this I mean the script does a merge from develop to pick-up 
non-submodule changes, followed by blind updating all submodules to 
their latest release (even if the merge from develop restored an older 
commit).  While there will still be a risk of module interoperability 
problems, this branch should generally work.  Its this material (and not 
submodule develop branches) that is proposed (but not yet accepted) to 
be part of the next release, so it's where automated integration testing 
should be done.

* Branch "develop": Maintained by release managers, who merge 
periodically from "latest" at commits that pass integration testing, and 
from feature branches that change non-submodule content.

This branch should be expected to be nearly-releasable at all times, 
since it references submodule releases that are known to interoperate 
and pass tests.  It's the best choice for module maintainers to branch 
from so they can detect interoperability problems with dependent modules 
before updating their own master branches.

For release preparation:

https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow#Releasepreparation 
specifies that a release branches from master, which is not how git-flow 
works: releases branch from develop, and merge to master. This becomes 
possible with the develop semantics I'm proposing, where develop is 
curated rather than scripted.

Also the comment about "branching for release early" seems inconsistent 
with git-flow's description that release branches are for last-minute 
cleanup and metadata updates.  I've found that, if you branch too early, 
you waste time shuttling patches between the release branch and the 
develop branch.  Branching when you're pretty sure you have a releasable 
system reduces rework.

Peter