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

Subject: Re: [boost] Request for comments on super-project workflow doc
From: Daniel James (daniel_at_[hidden])
Date: 2014-01-03 07:23:15

On 3 January 2014 08:25, Cox, Michael <mhcox_at_[hidden]> wrote:
>
> I agree.  The workflow maybe a valid scheme, but it definitely isn't Git
> Flow.  So either incorporate the above comments into the page or remove the
> reference to Git Flow.

Beman asked for feedback; you could try giving him a chance to incorporate it.

> Regarding the "latest" branch.  Technically you really don't need it as you
> can checkout the develop branch and use a "git submodule foreach" to
> checkout the HEADs of the develop branches in the scripts.

Then we'd have to identify each test run by over 100 hash values. It'd
also complicate the regression testing script, the amount of time it's
taking to get testing running illustrates why that's a bad idea. And
it would limit our flexibility in the future - it's easier to make
changes to how 'latest' is generated than it is to make changes to the
regression script.

> Also, any
> changes you make to the superproject would have to be first made in the
> "latest" branch and then merged into the develop branch (just more work and
> something to forget as most work will center around the develop branches).

As I've said elsewhere, as much content as possible should be removed
from the super-project in order to reduce this problem and others.
Super-project content is problematic regardless of the branching
scheme. What's left should be easy to update (e.g. index.html in the
root directory), or rarely updated.

Development should usually be based on a single branch, whether that's
latest or develop needs to be decided. Then transferring changes
should be pretty simple, especially since few people have write access
to the super-project.

My preference is to base content work on 'develop' and copy content
from develop automatically to 'latest', so that 'latest' is almost
completely automatic. Could perhaps use a custom merge from develop to
latest to make the history clearer (and things like 'git annotate'
would work better), but never in the opposite direction.

> latest=pu (proposed updates)

I'd rather avoid such an unfortunate acronym. Or is it a deliberate
comment on quality?