On Wednesday, March 13, 2002, at 05:26 PM, Ross Gardler wrote:
Thanks very much for this. I'll type this up as an xdoc from the point of
view of someone like myself. That "is how on earth can I contribute
efficiently to this project". The aim will be to answer questions like "I'
ve got this fix in my local version, how do I create a patch that the
commiters can apply without modification". I'll take a look at the
resources you mention, any other comments/resources from others will also
be included.
Some of this is already documented for all Apache XML projects http://xml.
apache.org/overview.html
I have no idea if this is the kind of thing that would be useful as an
xdoc for xindice (or other projects), but that's a decision the commiters
can make, at least I'll learn in the process. Thanks for the starter.
Ross
Michael Gratton wrote:
Ross Gardler wrote:
So can someone start me off...
Well, here's a few starting points that I've gleamed from working with
or on various projects, including large, free software projects (Mozilla,
FreeBSD), my own potterings, and projects at work.
I'm not saying Xindice should follow all of these suggestions off the
bat, but they are something to aim for as the project grows. I'd suggest
that the basic branch management (the first few points below) is
something to aim for initally.
** Branch management
Make a branch for every official release when it is feature-complete,
and tag the actual release code and any RC-style releases. Make RC-style
releases from the release's branch. Eg:
(note: a '|' indicates a tag)
==================================> trunk
\
\---|-----|-----| 1.0 branch
rc1 rc2 1.0
If you do make more, minor bigfixes to a release branch, you may as well
apply them to the same branch but use tags for the minor RC's (if any)
and for the minor point release. Eg:
==============================/ /======================> trunk
\
\---|-------|-------|-----/ /----|----------| 1.0 branch
1.0-rc1 1.0-rc2 1.0 1.0.1-rc1 1.0.1
If large, far reaching changes are being made on the trunk, such as
refactoring for an upcoming 2.0 release, but stable development work is
continuing the existing major release, do the stable work on a
long-lived, stable branch. Then make point releases from branches off
the stable branch, with each point release managed as above. Eg:
====================================> trunk (2.0 work)
\----------------------------------> 1.0 branch (ongoing stable work)
\--| 1.1 \--| 1.2 \--| 1.3
** Code and commit management.
Prior to cutting a new branch, freeze (close) the tree to all unapproved
commits to the branch you're cutting it from for a period of time (from
a few days up to a week). You don't want people landing destabilizing
changes just before you cut for a release.
Approval should also be sought to commit patches to a release branch.
Approval should be by some pre-determined process, such as the getting a
review by one or more commiters, for example, and when determining if a
patch should be applied, the people involved should include actaully
eyeball the proposed patches. On a closed or release branch, the only
patches that should be accepted are those which are throughly tested bug
fixes - no new features or large changes should land.
Use a bug tracking system such as Bugzilla. Fixes for particular bugs
should be attached to the bug itself as a patch so that it can be easily
reviewed and applied to multiple branches, if needed. If approval is
required and given, it can be recorded in the bug.
I'm sure I'll think of some more stuff, but the following are
interesting reading on the subject:
- General CVS guide for branching: <http://www.loria.fr/~molli/cvs/doc/
cvs_5.html#SEC49>
- The Mozilla hacking guide: <http://www.mozilla.org/hacking/>
Kimbro Staken - http://www.kstaken.org - http://www.xmldatabases.org
Apache Xindice native XML database http://xml.apache.org/xindice
XML:DB Initiative http://www.xmldb.org
Senior Technologist (Your company name here)
