on Fri Aug 03 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
And how did release procedures ever make our lives as developers difficult?
the long release cycle means that i have several sets of changes. Fixes for the current release. Others which are in the head but haven't been tested (except on my machine)
And how does that make your life difficult?
So from an individual developer's standpoint, its not really that great a problem anymore.
What isn't a problem?
If the trunk is going to be used as it has been - it will continue to be a problem
What is "it?" The trunk? The trunk is a problem?
for boost but not for me personally as I don't use it for testing.
Except for the tools we have to use - which is a whole other thread.
The one we ought to be spending keystrokes on. Or, better yet, work cycles. http://www.flynnfiles.com/archives/world_events2007/roll_up_your_sleeves.htm...
Well, actually, I have made a modest contribution to the toolset with my library status program. Admitidly, its not a large one but it did address some of my issues. Of course, not everyone will find it useful, but that's the way it is with everything. I don't find testing on the trunk useful.
The suggestion seems to have been made that I'm part of the problem because I've brought up the issue that things aren't working.
The suggestion seems to have been made (passive voice is a great way to accuse without being accused of accusing) that I'm suggesting you're part of the problem. 8-{ Don't take everything so personally. I don't have time to single anyone out for blame right now. If you want that, catch up with me in a few months; things may have cooled down for me by then ;-) There's certainly nothing wrong with raising the issue that things aren't working, and it's easy to think the process needs a complete overhaul... and maybe it even does. As Thomas said, though, you can't build an effective release process atop systems that are so unreliable. As Doug points out, many much larger projects function effectively with processes that are very close to what we're using. When it comes to release requirements, Boost is not so different from those other projects, so it ought to be possible to make our process work through a series of small, nonconvulsive adjustments. I find this logic very compelling. Therefore I want to fix the systems before making any adjustments to the process, and I will argue against attempts to make changes (especially large ones) in the process before the systems are fixed. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com