Re: [boost] Release procedure. Where do we go?

From: David Abrahams (dave_at_[hidden])
Date: 2007-09-03 12:17:13

on Mon Sep 03 2007, Roland Schwarz <roland.schwarz-AT-chello.at> wrote:

> Hopefully I am not seen as trying to add fuel to the fire, but I am 
> wondering if anyone tried to perform an analysis of what exactly did not 
> work with the (previous) release procedure.
>
> I have seen David Abrahams trying to analyze the current tools, but I 
> have not seen an analysis of the procedure and why it fails.
> (But I might have missed it in the long thread.)
>
> So I dare to ask the question again: What is wrong on
>
> 1)   working on trunk, the bleeding edge
>
> 2)   branching out for release when the trunk is
>       release-stable

Right there you've got a problem.  The problem is that the trunk will
never become release-stable on its own if it is allowed to become "the
bleeding edge."  So the release manager ends up freezing all checkins
on the trunk while we try to stabilize it, which takes forever.  In
the meantime, "nobody" else gets any work done, because "everybody"
thinks of the trunk as their own sandbox in which to do active
development.  Eventually some people discover they can work on a
branch while the trunk is frozen, but some people are still scared of
branching.

> 2.1) feature freeze and stabilizing, merging relevant
>       parts to trunk
>
> 3)   releasing from release candidate branch, i.e. tagging the branch
> 3.1) bugfixing on branch, merging to trunk, tagging the branch
>
> Is it this procedure that is broken, or is it the tools that are 
> insufficient to support this procedure?

The first problem, as I see it, is that the trunk is allowed to become
broken, and there isn't a great deal of immediate pressure on the
person who caused the breakage to fix it.  If the person doesn't have
access to the platform that broke, typically he just throws up his
hands and says "somebody who knows this platform will have to help
me," when instead he ought to back his changes out immediately.  We
need our tools to be able to test branches so that won't happen.

The second problem is that the list of tested release compilers has
shifted around unpredictably, so people often can't find out when
they've broken a platform until long after it's too late for an
immediate reversion of their changes to the trunk.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com