Policy RFC: branches/2.0 change process

[Christian Stimming]

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?

Christian