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

From: Stefan Seefeld (seefeld_at_[hidden])
Date: 2007-08-03 11:37:41

Douglas Gregor wrote:
> David Abrahams wrote:

>> Are you saying that 1.35 shouldn't be based on 1.34.1, or is it
>> something else? 
> I don't know what to do about 1.35.0. We need to get it out sooner 
> rather than later, and it seems that the build-it-from-1.34.1 approach 
> is the only way that's going to happen.
> 
> It's a band-aid, not a long-term solution, and it hurts us to prolong 
> the trunk/release divergence.

I totally agree. And in fact, this state of affairs is what prompted
me to start this discussion with the question about 'next steps'. I am
really hoping that, if some simple policies can be established quickly
after the svn switch, it will be far more easy to move forward than
by having two switches: one to svn (replacing 'HEAD' by 'trunk', but
no new policies), and one to a new development process (stable vs. branches).

>>  You said yourself that our trunk is a mess.
>>   
> Yes, and we need to fix the trunk, not devise elaborate processes to 
> isolate the "civilized world" of releases from the "wild west" of the 
> development trunk.
> 
> The title of this thread is "best practices" but the discussion has used 
> the term "policy". A best practice is a suggestion that developers are 
> free to ignore; a policy is a requirement that will somehow be enforced. 
> Which one are we discussing?

I'd suggest this:

* establish a 'stable' branch (by copying from RC_1_34_0). This is easy, and
  should be done *now*. (Then regression testing should be set up to monitor
  this branch's health.)

* establish goals for 1.35, notably by defining a list of accepted but otherwise
  new libraries to be added, and encourage library authors to work towards that
  goal (branching from 'stable', adding code, testing, submitting self-contained
  patches to be merged into stable, etc.). This should be easy, too: one trac
  ticket per new library.

* Discouraging developers to check *anything* into trunk any more, but instead,
  encourage the use of branches as a means to backport changes that now are in
  trunk, and should go into stable, whether in time for 1.35 or not.

There clearly are a lot of refinements and improvements that need to be done in
the above, but they all can be done incrementally. The important thing is to
get the ball rolling (into the right direction).

Thanks,
                Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...