[GRASS5] GRASS stable/exp branches

Malcolm Blue mblue at nb.sympatico.ca
Tue Feb 27 19:12:25 EST 2001

Markus, et al.,

I've been looking for information about how some of the other open 
source project manage the CVS branching / release cycle process.  
Unfortunately, there does not seem to be a lot of useful information for 
the current situation.

For now I think that we will have to rely on developers only submitting 
changes related to bug fixes which are on Markus's "RC" list.

Most of the sites describe how to submit patches to the CVS maintainers, 
but don't explain how they apply these to the release cycle.  They seem 
to limit the number of developers that actually maintain the CVS 
repository to a small select group, with the majority of developers 
relying on the few to maintain the source repository. 

One site that explains their process well is the apache jakarta site, 
particularly the turbine project.  Unfortunately, this mostly relates to 
larger subprojects (which might be useful after 5.0) and not to the 
alpha/beta/release process, and the handling of bug fixes in these other 
than to say " Simple patches to fix bugs can be committed then 
reviewed.".  They do not set up new branches for bug fixes.  With 
respect to branching, they use the "trunk" as the stable version and the 
"branches" for developmental subprojects.  This seems to correspond with 
the approaches outlined in the CVS book.  They have divided developers 
into developers and committers, and only the committers can actually 
apply changes to the CVS tree.  These subprojects relate more to the 
addition of new features in 5.1 than anything being undertaken for 5.0.  
Their source repository approach is described here:



Their approach does not seem appropriate for finishing off 5.0 stable.  
I think that it may be more useful for moving toward 5.1. So maybe for 
some of the 5.1 ideas that have been identified, different branches 
could be started (later).

Since they refer to the CVS book, I've included a link to the start of 
the relevant sections:

I don't think you want to have to apply patches submitted by a large 
group of developers, which seems to be the approach that many of the 
projects take.  Even if these were done by a group of people, this would 
take the people doing most of the changes away from working toward the 
stable release. 

I visited a number of the better known project sites and only the 
jakarta site provided very detailed and relevant information for the 
development model that you (Markus) have set up.  After reading this 
though, I realized the information at many of the other sites seems to 
be consistent, just less detailed. 

At the very least the information at the above site should provide some 
food for thought for future releases.


Markus Neteler wrote:

> Hello Justin, hi all,
> thanks for your long "branch" letter. It seems to be more
> problematic than expected.
> For me I can say: I prefer *less* work by branching. It would be
> impossible for me to check all contributions to the stable branch 
> as I have real life work to do as well (not to mention the Ph.D. idea).
> Maybe, to speed up, we should choose the src/CMD/lists/GRASS
> idea and have a dead-end-branch for 5.0.0 only. I am still
> believing that we should switch over immediately to 5.1 rather
> then spending more time on 5.0. Then we can get familiar with all
> this branching stuff etc.
> The idea I was following for some days seems to have so many side
> effects... Thanks Justin and Bernhard for your comments.
> Well, any further idea here how to proceed with stable?
> Markus
> ---------------------------------------- 
> If you want to unsubscribe from GRASS Development Team mailing list write to:
> minordomo at geog.uni-hannover.de with
> subject 'unsubscribe grass5'

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

More information about the grass-dev mailing list