Subject: Re: [boost] [git] Update submodules in boost.git
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-08 03:34:33
On Saturday 07 December 2013 14:45:21 Dave Abrahams wrote:
> Andrey Semashev <andrey.semashev_at_[hidden]> writes:
> > On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev
> >> So this basically means that each library has to have its own testing
> >> farm, and Boost serves mostly the bundling purpose. A possible
> >> solution, I guess, but not sure such approach would be beneficial for
> >> the quality of Boost. I doubt that individual developers will be able
> >> to do the same amount of testing for their library releases as they
> >> had with svn.
> > Actually, thinking about it some more, this doesn't look as a good
> > approach at all. First, the develop branch for the submodules becomes
> > unneeded by the superproject. Individual developers may use it at
> > their discretion but it doesn't matter in the big picture.
> And why is that a bad thing? The only purpose of the superproject is as
> a way of tracking releasable states of the whole library collection.
What about testing? To me, the collection is in a releasable state when the
testing results show no blocker problems, and this is not a precondition for a
given superproject state. It's the other way around - the superproject state
accommodates changes from the libraries and every such snapshot is tested
whether it is suitable for being released.
In the rest of my last quoted message I described why the particular approach
for testing could result in negative outcome - problems in the dependent code
are not detected by testing until the problematic code is merged to master. It
takes longer time for the fix to travel from develop to master again. Later in
the discussion Peter assured me that the release managers' job would be to
manually select which commits to master are problematic ones and exclude them
from the Boost release. This sounds like a tedious task to me, but it would
remove the delay in the Boost release at least. But still it doesn't help
individual developers since their tests would be broken for longer times and
integration problems not detected early.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk