[GRASS5] GRASS stable/exp branches
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
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?
> 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