Re: [boost] [SVN]Best Practices for developers using SVN

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.

1000% agreed.

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

Yep.

> 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
humans.

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