[GRASS5] Splitting GRASS 5 into stable and unstable

[John Huddleston]

To Grass developers list,

I have used CVS from 1991 to present.  I oversaw the work of
25 different project teams, about 65 feds and 125 contractors
for USDA NRCS as a configuration manager.  I also have
built CVS for ARS and recently worked with them to configure 
their CVS as well as use the jCVS and WinCVS clients.  I
have given CVS training in the last two years to three different
groups.

Doing branches is necessary when there are code changes that
break the system.   Making fixes or patches to the HEAD of
a CVS repository do not usually require a branch.  Communication
such as the recent CVS announcement by Bernhard is one
of the key elements of using CVS together.   So, the question
to ask is what breaks the system?

Any code that changes a function name, function variables,
number of function variables, adds new external variables,
and like scenarios is cause for making a branch.  New code
that uses the older code does not require a new branch.  
Further, branching can be done by any individual but merging
is done by the group.  Announcing before-hand that a merge 
is about to happen (so we can all update our local files
first!) is being handled great by Markus.

John Huddleston, P.E.
USDA Computer Engineer
huddleston at gpsr.colostate.edu 
(970) 490-8352

----- Original Message ----- 
From: Bernhard Reiter <bernhard at intevation.de>
To: <grass5 at geog.uni-hannover.de>
Sent: Tuesday, May 09, 2000 3:43 PM
Subject: Re: [GRASS5] Splitting GRASS 5 into stable and unstable


> On Tue, May 09, 2000 at 11:54:42AM -0400, Eric Mitchell wrote:
> > "When To Branch" is one of those fundamentally  tricky 
> > questions of software development.  
> 
> I am almost certain that we need to branch. 
> That means, we need a road leading to a very stable grass5.0 
> and another that leads to new development version and a cleanup
> of grass. But I agree that it is a tricky question.
> 
> > What this branch is trying to accomplish is (as I understand
> > it, feel free to correct me here) to protect the architectural
> > integrity of the pending grass-5.0 release.
> 
> Yes.
> 
> > The fundamental question here is (again, IMHO) "Are
> > there pending significant changes to the grass-5.x 
> > code base?"  I haven't followed the developer list 
> > long enough to know the answer to this.
> 
> Again, yes. Markus pointed them out in his next post.
> 
> If we agree that we need a stable and a development tree we have
> at least two technical options of implementing the scheme.
> One is to use the branch feature of CVS, the other is to
> create a parallel fresh module tree in CVS.
> 
> David was raising exactly this issue.
> And this is another difficult question. I tend towards the
> cvs branch method right now. Structural changes will still be possible 
> within CVS. You can remove files from certain cvs branches.
> 
> I assume that even in the development version a lot of GRASS huge
> codebase and filesnames will stay the same. The technical advantage in
> using CVS branchen then is, that only the changed files and directories
> actually will be kept two times in the repository. And it will be
> possible to merge generall patches relatively easy. It is also a lot
> easier to switch to a seperate CVS tree from a CVS branch as the other
> way round.
> 
> Just my 0.02 Euro,
> Bernhard
> 
> -- 
> Professional Service around Free Software
> (intevation.net)  
> The FreeGIS Project
> (freegis.org)
> Association for a Free Informational Infrastructure
> (ffii.org)


---------------------------------------- 
If you want to unsubscribe from GRASS Development
Team internal mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
length: 4985
max: 0