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

From: David Abrahams (dave_at_[hidden])
Date: 2007-08-03 20:13:30

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