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