From: David Abrahams (dave_at_[hidden])
Date: 2007-08-03 10:43:27
on Thu Aug 02 2007, Doug Gregor <dgregor-AT-osl.iu.edu> wrote:
> Volodya is absolutely correct. Delaying integration of new work by
> using more branches will not fix problems; it just delays them.
True, but delaying these problems can make for a sane environment in
which one can develop a feature without being upset every few days
while someone else works on correcting the bugs he's checked in.
> Frankly, I think this whole approach of "fixing the process" is
> wrongheaded. We're in this mess because our *tools* are broken, not
> our *process*. Lots of other projects, many larger than Boost, work
> perfectly well with the same or similar processes because their tools
> work better.
I'm 100% convinced the tools are broken. I'm only about 50% convinced
that the process isn't (or is, if you prefer) broken.
> What doesn't work? Regression testing.
> Thomas Witt has pointed out the myriad problems with our testing
> setup that affected the Boost 1.34.0 release. He should know: he
> managed the 1.34.x release series. I hit exactly the same problems
> when I managed the 1.33.x release series. Report generation stalls
> every few days, cycle times are horrible, it's impossible to isolate
> what checkins caused failures, and we only really have our testers
> testing one thing at a time. So either we aren't stabilizing a
> release (because we're testing the trunk) or the trunk has turned
> into an untested wild-west because we *are* stabilizing a release.
> That wild-west went on for a *year* while we were stabilizing the
> 1.34.0 release, so our trunk is, of course a mess.
> At one point, I thought we could fix this problem with a stable
> branch based on 1.34.1, from which future releases would occur. Now,
> I'm convinced that is the absolutely wrong approach.
Are you saying that 1.35 shouldn't be based on 1.34.1, or is it
something else? You said yourself that our trunk is a mess.
> It means that "trunk" and "stable" would be forever divergent, and
> would rely on manual merges to get features into stable.
Again I'm falling victim to a lack of clarity about what these names
mean. "stable" is presumably the place from which we spin releases?
What's "trunk?" The wild west?
> That's a recipe for unwanted surprises, because library
> authors---who typically work from the trunk
Well, that may be part of the problem. We may need to get authors
over their fear of branches.
> ---are going to forget to merge features and bug-fixes (including
> the test cases for those things) to the stable branch, and BOOM! No
> progress. It's more work in the long run to require so many small
> merges, and it really is just a way to avoid doing what we really
> must do: fix the trunk. If our trunk were well-tested, release
> branches would be short-lived and the risk of divergence (features/
> fixes not making it between branch and trunk) would be minimized.
As long as the number of bugs on the trunk were always close to zero,
as it should be, I think that's right.
> Plus, developers wouldn't need to manually merge anything *except*
> the few things that are needed for those short-lived release
> branches. Since we now have Subversion, svnmerge.py can even make it
> easy to deal with those merges relatively easily.
> P.S. Here are some of the many things I could have done that would
> have been more productive than writing the message above:
> 1) Made regression.py work with Subversion, so that we would be
> performing regression testing on the trunk.
> 2) Looked at the changes made on the RC_1_34_0 branch to determine
> which ones can be merged back to the trunk.
> 3) Fixed some of the current failures on the trunk.
> 4) Setup a new nightly regression tester.
> 5) Studied Dart2 to see how we can make it work for Boost
> 6) Investigated the problems with incremental testing.
> 7) Improved the existing test reporting system to track Subversion
> revisions associated with test runs, and link to those
> revisions in the Trac.
> 8) Improved the existing test reporting system to track changes from
> day to day
> Before I reply to any messages in this thread, I'll be thinking about
> that list. Will you?
I wish you'd put that list at the top of your message. ;-)
> P.P.S. I know I sound grumpy, because I am. The amount of time we
> have collectively used discussing policies would have used far more
> wisely to improve the tools we have.
I agree with that. I've become suspicious of technological solutions
over the years, but maybe I should be even more suspicious of process
solutions, especially when those processes have to be followed by
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk