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

Subject: Re: [boost] [git help] Documenting common modular boost workflows
From: Beman Dawes (bdawes_at_[hidden])
Date: 2013-10-21 21:18:27

On Mon, Oct 21, 2013 at 8:11 PM, Niall Douglas <s_sourceforge_at_[hidden]>wrote:

> On 21 Oct 2013 at 12:28, Beman Dawes wrote:
>
> > 1) What git/TortoiseGit/other commands would a Boost library maintainer
> > have to execute if, after following
> > https://svn.boost.org/trac/boost/wiki/TryModBoost, they wish to fix a
> > simple bug in their "develop" branch?
>
> TortoiseGit hides "gitness" from the user by often executing more
> than one git command than is obvious. Hardcore git users get upset by
> this, but I personally don't mind except when command line git
> doesn't do what I expect because I've become too used to TortoiseGit
> (e.g. changing a file while editing a commit message commits the
> changes on TortoiseGit, but does not on command line).
>

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.

>
> > For that matter, does a Boost library maintainer even start by
> > https://svn.boost.org/trac/boost/wiki/TryModBoost? Is there a more
> > preferable approach?
>
> That page basically clones and checks out a kitchen sink Boost with
> all possible git submodules. That rather makes modularisation
> pointless.
>
> 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.

>
> > 2) What git/TortoiseGit/other commands would a Boost library maintainer
> > have to execute if, after (1) they wanted to merge it into their
> library's
> > "master' branch?
>
> 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?

>
> 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?

> I think the hard part there is who
> admin's that process.
>

The admins for the super-project are the boost release managers.

--Beman