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 Kimbro Staken <ks...@xmldatabases.org> on 2002/03/11 23:12:54 UTC
[vote] 1.0 release
I'd like to propose that we go ahead and get a 1.0 release out. Almost all
the issues I'm seeing are related to things that we're not planning to fix
until 1.1 so we really need to get going on that.
There's one patch from Mike that still needs to go in, but it's just
example code so nothing major. I'll add it before building the release.
Also even if we don't release 1.0 now I think we should put bug fixes onto
a branch so that we can open the trunk for new development. Branches are a
pain, but we need to get new development ramped up again.
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 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.
Commit Policy
Posted by Ross Gardler <rg...@wkwyw.net>.
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: [vote] 1.0 release
Posted by Michael Gratton <mi...@vee.net>.
Kimbro Staken wrote:
> I'd like to propose that we go ahead and get a 1.0 release out.
+1.
> I think we should put bug fixes onto a branch so that we can open
> the trunk for new development. Branches are a pain, but we need to
> get new development ramped up again.
I'm all in favour of using branches for release management. It can be a
right pain at times, but it always makes life easier for concurrent
development in the long run. If a 1.0 branch isn't cut, then there's
going to be no hope of releasing bugfix/feature-backport 1.0.x versions
once new features start landing and destabilising the trunk.
One thing I've noticed is that branch management tends to be much easier
if all changes to the tree start out life as patches. It's then very
simple to commit the patch to one or more branches as needed.
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.
But I hope I'm preaching to the converted here.. ^_^
Mike.
--
Mike Gratton <mi...@vee.net>, <http://web.vee.net/>
Leader in leachate production and transmission since 1976.
Re: [vote] 1.0 release
Posted by "Mark J. Stang" <ma...@earthlink.net>.
+1 to release 1.0.
Jeff Suttor wrote:
> +1 to release 1.0.
>
> we will upgrade our UDDI application with 1.0 when it becomes available. we can then participate in finding/fixing bugs.
>
> --
> Jeff.Suttor@Sun.com
>
> Kimbro Staken wrote:
> >
> > I'd like to propose that we go ahead and get a 1.0 release out. Almost all
> > the issues I'm seeing are related to things that we're not planning to fix
> > until 1.1 so we really need to get going on that.
> >
> > There's one patch from Mike that still needs to go in, but it's just
> > example code so nothing major. I'll add it before building the release.
> >
> > Also even if we don't release 1.0 now I think we should put bug fixes onto
> > a branch so that we can open the trunk for new development. Branches are a
> > pain, but we need to get new development ramped up again.
> >
> > 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)
>
> --
> Jeff.Suttor@Sun.com
Re: [vote] 1.0 release
Posted by Jeff Suttor <Je...@Sun.COM>.
+1 to release 1.0.
we will upgrade our UDDI application with 1.0 when it becomes available. we can then participate in finding/fixing bugs.
--
Jeff.Suttor@Sun.com
Kimbro Staken wrote:
>
> I'd like to propose that we go ahead and get a 1.0 release out. Almost all
> the issues I'm seeing are related to things that we're not planning to fix
> until 1.1 so we really need to get going on that.
>
> There's one patch from Mike that still needs to go in, but it's just
> example code so nothing major. I'll add it before building the release.
>
> Also even if we don't release 1.0 now I think we should put bug fixes onto
> a branch so that we can open the trunk for new development. Branches are a
> pain, but we need to get new development ramped up again.
>
> 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)
--
Jeff.Suttor@Sun.com
Re: [vote] 1.0 release
Posted by Stefano Mazzocchi <st...@apache.org>.
Tom Bradford wrote:
>
> On Monday, March 11, 2002, at 03:12 PM, Kimbro Staken wrote:
> > I'd like to propose that we go ahead and get a 1.0 release out. Almost
> > all the issues I'm seeing are related to things that we're not planning
> > to fix until 1.1 so we really need to get going on that.
>
> +1
+1
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: [vote] 1.0 release
Posted by Kimbro Staken <ks...@xmldatabases.org>.
Ok, looks like we're a go for this.
On Tuesday, March 12, 2002, at 08:53 AM, Tom Bradford wrote:
> On Monday, March 11, 2002, at 03:12 PM, Kimbro Staken wrote:
>> I'd like to propose that we go ahead and get a 1.0 release out. Almost
>> all the issues I'm seeing are related to things that we're not planning
>> to fix until 1.1 so we really need to get going on that.
>
> +1
>
> --
> Tom Bradford - http://www.tbradford.org
> Architect - XQRL (XQuery Engine) - http://www.xqrl.com
> Apache Xindice (XML Database) - http://xml.apache.org/xindice
> Project Labrador (Web Services) - http://notdotnet.org/labrador
>
>
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: [vote] 1.0 release
Posted by Tom Bradford <to...@xqrl.com>.
On Monday, March 11, 2002, at 03:12 PM, Kimbro Staken wrote:
> I'd like to propose that we go ahead and get a 1.0 release out. Almost
> all the issues I'm seeing are related to things that we're not planning
> to fix until 1.1 so we really need to get going on that.
+1
--
Tom Bradford - http://www.tbradford.org
Architect - XQRL (XQuery Engine) - http://www.xqrl.com
Apache Xindice (XML Database) - http://xml.apache.org/xindice
Project Labrador (Web Services) - http://notdotnet.org/labrador