You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Ross Gardler <rg...@wkwyw.net> on 2002/03/12 11:30:07 UTC
Commit Policy
Michael Gratton wrote:
> In the end, most of the pain caused by branches can usually be solved by
> having a well thought out commit policy and ensuring all comitters stick
> to that.
Actually there is at least one person on this list that is still
learning about working with CVS in a distributed project. Whilst I do
not have commit status, and do not expect to get it for a potentially
long time I would like to know what is considered a "well thought out
commit policy".
In return I will write up the suggested policy for the developer docs.
So can someone start me off...
Ross Gardler
Re: Commit Policy
Posted by Kimbro Staken <ks...@xmldatabases.org>.
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)
Re: Commit Policy
Posted by Ross Gardler <rg...@wkwyw.net>.
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.
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/>
>
Re: Commit Policy
Posted by Michael Gratton <mi...@vee.net>.
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/>
--
Mike Gratton <mi...@vee.net>, <http://web.vee.net/>
Leader in leachate production and transmission since 1976.