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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
