[GRASS5] Using CVS to manage "experimental" vs. "stable" trees

[Carl Worth]

I've been reading the "GRASS CVS and release strategies page"[1] as
well as following the release plans on this list. I think there are
some good systems in place, but I think we could use some improvement
as well.

I wrote up a long and rambling email, and after having done so, I
think I can summarize it to a few points:

	o The proposed use of branches to manage releases is a Good
	  Thing.

	o Using a separate CVS module, (ie. grass51), for the
	  experimental tree is problematic for a few reasons. It has a
	  fracturing effect on the development community. Note how
	  underutilized this tree is. Think ahead about the
	  logistical problems involved in turning the grass51 tree
	  into the "stable" tree, (getting all developers to shift
	  over, renaming things on web pages, etc.)

	o The need for parallel development is not great. It really
	  only exists during the transitions when one "experimental
	  tree" of GRASS becomes the new "stable tree".

	o Parallel development, (when necessary), is best handled with
	  branches in CVS.

Proposal: Sometime after GRASS 5.0.0 is released, and when the
development community feels the time is right, the experimental code
in the grass51 module should be placed at the head of CVS in the grass
module.

I'll include my long and rambling email below that goes into more
detail on several of these points.

I'd be very interested in hearing reactions/discussion about these issues.

-Carl

-- 
Carl Worth                                        
USC Information Sciences Institute                 cworth at east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203		  703-812-3725

PS. Here's what I wrote earlier:

First, I like the plan currently in progress for making a stable
release. Namely, code is developed on the head of the CVS tree. When
the code reaches a point at which it is worth releasing, a release
branch is created in CVS, (I don't know what tag naming convention
will be used for the branch, something like
"RELEASE_5_0_0_branch"?).

Then, no development will occur along that release branch, but only
release critical bug fixes, (which must be simultaneously applied to
the head of the tree). After some testing/fixing cycles, the branch
will be determined releasable and will be tagged (something like
"RELEASE_5_0_0"?), and released.

At that point, if I understand things correctly, that release branch
will not have any work done on it after that. The 5.0.1 release will
not come from an extension of the 5.0.0 branch, but will instead be a
new branch off of the trunk at some later time.

Am I correct with all of this so far? Now I'm getting to the point I
want to make.

Within CVS there is currently a separate module for grass51, (which is
an experimental tree for exploring incompatible changes to GRASS in
parallel with the development efforts on the stable tree).

One problem with the grass51 tree is that it has been extremely
underused, (as mentioned on the web page above). I think this is
largely due to the fact that there are a limited number of GRASS
developers and most attention has been focused on the stable tree.

However, there have also been many features proposed on this list that
have received a reaction of "save that for grass51". I have proposed
several of these features myself, and discovered that I couldn't
directly implement them in the grass51 tree since not all of GRASS
exists there yet, (much of it is simply copied over from the stable
tree during compilation).

And, eventually, the code being developed within the grass51 tree must
become the new stable tree. So at some point, all of the developes
that are currently working on the "stable tree" must be shifted over to
what is now the "experimental tree" and the trees must be
renamed. This is a severe logistical problem, (informing developers
what to do and when, updating lots of grass/grass51 references on many
web pages, trying to make sure that developers don't get lost
wasting effort developing on an old and useless tree).

So, to address that issue, I would like to propose an addition to the
system. I propose that at some point, the "experimental tree" should
be officially designated as the primary development effort. In order
to do this, the code from the experimental tree should be merged into
the head of CVS on the stable tree. That way, developers are easily
pulled along in the new direction of GRASS, and if we're careful, web
pages can remain with the original text.

At that point, the effort on the head of CVS will be geared toward
making a new stable release, (eg. 5.2.0 will be the next one). If
there is actually interest in simultaneous mainenance of the former
stable releases, (eg. 5.0.x), then this could occur in parallel along
the last 5.0 release branch. This would be the only time development
would occur on a release branch and would only happen if the new
stable branch was taking too long to come about for somebody.

Finally, if such a system make sense, it would be much easier to
implment if the "experimental tree" were implemented as a branch
rather, (if necessary), rather than a separate module. This would make
the merge much easier, and would eliminate the current awkward "copy
code from some other CVS tree" implementation.

To summarize, code development would always occur on the head of CVS
in one module. Test/debug cycles for each release would occur on short
branches. Parallel development, (which is by nature splintering),
would only occur if needed and would take place on the last stable
release branch, (if someone wanted to continue to maintain a stable
release after the core team had moved on), or on an "experimental
branch", (if someone wants to get a head start on experimentation
before the core GRASS team decides to).

-Carl

[1] http://grass.itc.it/codemanagement.html

PPS. For the truly sadistic who want to read even more rambling prose
from me, here's something I wrote even earlier as I was first
collecting my thoughts on all of this:

As for grass51, I'm perpetually confused by the way this is handled in
CVS. I understand that we are making fundamental changes to things
like the vector engine as well as re-organizing all of the code
structure, (which is very much needed). But I don't see how I can make
good use of the grass51 development tree as it currently exists.

For example, let's say I want to hack away on the display driver
interface. But, it doesn't actually exist in grass51 CVS. Instead, it
is merely copied over during compilation from the main grass CVS
tree. So, there is no way in CVS to actually work on this code, (at
least, not until it all gets moved over. What's the plan for that).

And even then, after all the code is restructured into the grass51
tree, there's no easy way to communicate and coerce developers to stop
working on the old grass tree and start working on the new grass51
tree, (as opposed to simply merging a "grass51" branch back into the
head of CVS once it is determined stable enough for general
development).

Similarly, I don't get a warm fuzzy from naming a top-level CVS module
with an embedded version number, (51). It seems to me that version
numbers should be used to tag code when it gets to a particular
development state, not to name the code, (especially not "a priori" as
in this case). Cross-reference to recent post suggesting problems with
needing to increment a major the middle version number to make a new
5.1.0 release after making incompatible changes to 5.0.x).

So, in summary, why is the re-organization of the code for "grass51"
taking place inside a new CVS module with an embedded version number
rather than within a CVS branch for example? When new features are
proposed to the list, I often see responses of the form, "Save this
for Grass51" -- yet, currently, there's no way to actually work on
grass51 so the work is necessarily slowed down.

-Carl