Policy RFC: branches/2.0 change process
stimming at tuhh.de
Fri Jul 14 15:30:13 EDT 2006
Am Donnerstag, 13. Juli 2006 01:33 schrieb Derek Atkins:
> > Instead, if the fixes are made on /branches/2.0, then the branch can
> > be repeatedly pulled into trunk. Essentially, /trunk is constantly
> > being rebased off the tip of /branches/2.0. This won't suffer any
> > divergence, because all previous changes to /branches/2.0 will already
> > be in /trunk.
> This is why I'd like a real process.. If each change destined for
> 2.0 requires a bugzilla report, then that bugzilla report can contain
> the changeset revision(s) in trunk. The work required is the same
> regardless of whether you merge that changeset from trunk->branches/2.0
> or from branches/2.0->trunk -- as the branches diverge it's going to be
> the same amount of work.
> Merging a single changeset is very simple so long as you know what that
> changeset is.
I see that http://wiki.gnucash.org/wiki/Development_Process has been started
to collect the final agreement.
Basically I'm fine with all proposals so far, except that I have one question:
How do we ensure that bugfixes on trunk are really 1. audited and 2. merged
to the release-branch and not forgotten? E.g. I have already lost track of
which trunk changes are to be merged to branches/2.0 and which ones are not.
And additionally trunk changes that should be merged to the 2.0-branch need to
keep track of the status - the status can either be #1 "awaiting audit", or
#2 "audited, awaiting merge to branch-2.0", or #3 "finished". How and where
do we keep track of that? Bugzilla? Then we'd need an easy way for the
mapping between the trunk-changeset and the bugzilla-number, and I can't see
a technical solution for this which would *easily* work. More ideas?
More information about the gnucash-devel