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

[Bernhard Reiter]

On Tue, Apr 23, 2002 at 03:14:28PM +0000, Carl Worth wrote:
> 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.

We are welcome to suggestions.
Note that in my view we really have to start making one interation
before we can fine tune. In the last years there were several
discussions never leading to a tarball release of grass 5 called stable.
This is why ours plans got more aggresive.

GRASS is a huge project, we need to make a stable release somehow 
and slowly adjust the users that we have now an open development.

Because of the conservative user base and the developers
that mostly are not software engineers, we have to take small steps.


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

This is known, but still an improvement.
GRASS is a huge project, we have to divide it so 
programmers can conquer it.

It is the result of intensive discussions on 
how to progress on separate tracks. Now Radim could start on the
vector code which is great.

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

It was even messier before.
It was not clear what was development code and what is stable.
With people regularily pointed to the development versions in the cvs.
Most users want a stable release. 
Many people want additions in all directions.
If we let everybody do this on one tree, we never get a release.

And technically it is easy, just declare check out the
grass51 version you want and create a new stable tree, called grass52.
No need for renaming.

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

My experience in the last years is that users are very conservative
and do want very stable code.

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

I'm glad that CVS acceptance is growing with GRASS developers.
Branches are still magic for many.
Thus we will not use them in even more complicated ways.

On the other hand, directory reorganisation within a tree 
with CVS is difficult, we had to use subversion or other revision
control system for this.

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

Looses history and is complicated.
Will not provide enough parallel development possibilities.

> PS. Here's what I wrote earlier:

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

Yes.

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

No. 
The analysis on the release strategy pages dates back to november 2001.
After that Radmin started to use the grass51 for exactly the right purpose.
Thus usage is as planned now.

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

We hope to get developers to help us to get the stable release out.
Next big step is reorganisations and we also hope for more modularisation.
Then there will be more room for experiments.

Thus you can :
	a) make your own branch for experimentation on grass5
	if you really must. You will be fully responsible for
	releasing anything of this or folding in at some time.

	b) help to bring over modules you need to grass51
	(very appreciated)

	c) help to make the stable release that other people will
	have more time to populate grass51.
	
> 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. 

As pointed up above there will be no renaming.
Please note that many people rejected CVS at first, 
because of the additional buraucracy as they saw it.
Now it saves time.

The next paragraphes will indoce missunderstandings about 
what you reall want to archive:

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

We need to get more formalised procedures to do this,
this is very clear from past experiences.
We cannot avoid structuring it.

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

Trust me on this, we are not ready for this.
Massive code reorganisation with a huge project like GRASS 
better happens in a fresh cvs tree.

I'm very glad for your analysis though,
as the stream of thoughts is similiar to mine.
I hope that I've writen down many of the subconditions
that convince me that we are on a good path without
immideate need to refine it.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 248 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20020423/b7287351/attachment.bin