Re: [boost] [git help] Documenting common modular boost workflows

Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-10-21 21:55:02

On 21 Oct 2013 at 21:18, Beman Dawes wrote:

> Some developers will prefer GitFlow. Others will use the command line. And
> still others with use other tools. We have to support all of them with at
> least minimal documentation.

I assume you mean the tools rather than the processes here. In which 
case fine, let each library maintainer do as they wish.

> > What we really need is for each Boost module to specify its
> > dependency Boost modules, and that way only the git submodules needed
> > are cloned. Therefore if I want to use Boost.AFIO in my project, AFIO
> > will specify it needs Thread and ASIO and those get git submodule
> > update --init --recursive.
> 
> Maybe someday, but not now.

It's much easier than you think you know. If you insist on a 
mandatory script in the root of each submodule e.g.

fetch-boost-dependencies.sh
fetch-boost-dependencies.cmd (which simply CMD's the former BTW)

All that does is call git update --init --recursive for those 
libraries it depends on. This can work because it is safe to 
repeatedly call that command on an already initialised submodule.

It surely is then extremely easy to have Boost.Build check for the 
presence of that script and execute it if present. Voila, automatic 
dependency fetching.

> > I think the only sane way is to have the master Boost master repo
> > track which SHA in a submodule's master branch is the sanctified
> > known true stable incarnation of the library. A library can commit
> > what they like to whatever branch - and we can't stop them. But we
> > can gatekeep which SHA in that repo is considered valid by master
> > Boost master.
> 
> Un, didn't you just describe how a git sub-module works?

In implementation, yes. I was trying to describe the work flow as 
that's what I thought was being asked.

(I did so because I have noticed occasional confusion about git here, 
so I thought it would set the context and help avoid confusion)

> > We do indeed need a process for automating that, unless you want to
> > give write access to the master Boost master repo to all Boost
> > authors (I assume you don't!).
> 
> Wouldn't the sub-module developer just send a pull request to the
> super-module?

They could, but it's awkward because they have to:

1. Pull changes into their fork of super-module from base.

2. Commit submodule ref update to their fork.

2a. Check that newly merged super-module and module compiles and 
passes all tests.

3. Issue pull request to base.

I worry you see about 2a: will people tend to skip that part? One 
part of a solution could be requiring Travis CI report good before a 
pull request will be accepted (Travis becomes an option with 
modularised Boost, few individual libraries will take more than 30 
minutes to compile).

I worry that the super-project admin is very likely to accept all 
pull requests sent without deeply checking what they mean - after 
all, they're just a submodule ref update with no explanatory context. 
I agree we already accept this in SVN, but people commit to SVN 
knowing they are being watched.

I also worry that every library maintainer having to keep a complete 
set of upstream forks for issuing pull requests might scare people a 
bit. It's also a bit involved.

Lastly, I worry that bisecting all this to find cause of breakages is 
probably hard.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/