Re: [boost] Boost Development Environment proposal

From: troy d straszheim (troy_at_[hidden])
Date: 2007-06-08 13:02:13

On Wed, Jun 06, 2007 at 08:40:52AM -0400, David Abrahams wrote:
> 
> I've been asking myself why we're still talking about a "trunk," too.
> Can somebody explain why, and what it's supposed to mean?
> 

Heh, nobody bit on this one.  I'm feeling brave, I'll give it a try.

'trunk', as we CVS users typically understand, is data.  It's where
you commit if you're a developer.  It's a single branch in a single
repository.  If you want the latest stuff, you check out the 'trunk'.

But this sense of 'trunk' also implies the typical CVS development
process: everyone synchronizes their work to that one branch, and when
that is stable, a branch is made for release; great effort is made to
keep all development on one copy of the source tree, as
branching/merging is typically difficult and expensive; etc.  Since
CVS is made to support development in a particular way, that way is
fundamental to our understanding of 'trunk'.

So to talk about the 'trunk' in a CVS-less environment is to either be
vague or to imply that the development process is CVS like.  You're
talking about a location, and given is that the tools will dictate
workflow (it's the trunk, of course, everybody knows what the trunk is
for, there's no other way to do things)... but in the absence of CVS
that isn't the case.  You're leaving the workflow undefined.

I thought about this question as I rewatched the talk this morning:
Linus is extolling the virtues of being distributed and outlines a
scenario, the release process, wherein the development group is
happily developing along on their branch.  The verification group is
pulling down code (that is, merging code into their branch) from the
development group's branch as they like, tweaking a bit, doing their
thing.  The testing group, similarly, pulls down (merges) code from
the verification group, tests, and gets releases out the door.

As he describes it, all three groups are working, all the time.
Upstream groups are for the most part blissfully unaware of what is
happening later in the pipeline, except, presumably, to the extent
that they get interrupted to assist with particularly nasty bugs or
whatever.  (You could imagine a need to merge code backwards up the
pipeline if the code that the development group was producing diverged
enough from the testing group's code that merging stopped working.)
There is a constant flow of code through this pipeline; predominantly,
but not exclusively, in one direction.

So, where's the trunk?  Do all of these branches represent one
composite trunk?  The testing group may have patches that the
development group never knows about, as testing is always merging
changes in to what they've already released.  

So you could say that there is no 'trunk' in the scenario above...
Perhaps there are many, all along this pipeline, a composite 'trunk',
many locations in many repositories.  But that's not the whole story
since those repositories are useless without the pipeline behavior
that makes them 'trunk'.  Think separation of data structures and
algorithms.  Trunk is a process *and* the data that it operates on.
There are many varieties, and we tend to imply the CVS kind.

I notice some paralllel between the devel-verification-testing
pipeline that Torvalds describes and the proposed stable-devel boost
pipeline.  The abolishment of 'trunk' in favor of these other terms
might make good sense; at least the terminology won't excite incorrect
assumptions about the process.

There.  I gave it a shot.

-t