Policy RFC: branches/2.0 change process

[Derek Atkins]

Christian Stimming <stimming at tuhh.de> writes:

> I see that http://wiki.gnucash.org/wiki/Development_Process has been started 
> to collect the final agreement. 

Yeah.  Chris and I worked out our differences in irc.  Basically, he
thought that I wanted the release branch to only contain already-tested
fully-integrated code.  I just want to make sure all patches are
individually audited and vetted before being back-ported.

> 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. 

I've created a catch-all bug in bugzilla for this.  See
http://bugzilla.gnome.org/show_bug.cgi?id=347575 for more info.  I've
added info about this to the wiki page.  At least that will help solve
#2.  Solving #1 is a little more difficult.  One way we could do it is
by notes in bugzilla.  Another way is email or IRC.

> 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?

It's easy to map from the backport changeset to the trunk changeset.
During the merge from trunk->release the commitlog just needs to say:

  merge from r12345

If, however, we need the backwards link then the only thing I can
think of is editing the commitlog after the fact or linking through
bugzilla.

If we keep track of bugs to get merged in bugzilla then the only real
question is how to differentiate state #1 (awaiting audit) from state
#2 (audited, awaiting merge to release branch).  Unfortunately I don't
have a good approach to that, yet.  Certainly we can add an "I've
audited this changeset and think it's correct" statement in bugzilla.
Another option is to create another catch-all bug, a "request audit"
bug.  So you add a bug to the "request audit" bug first, and then once
it's audited you add it to the "request backport" bug.  And then when
it's backported the bug is closed.

This, however, is a LOT more work.  If other developers are happy with
that extra work I'm happy to live with it, but I WAS trying to
minimize the process.

Another thing that Chris and I were discussing on IRC last night was
changing the subject line of commit messages when a backport is
requested.

I think this part of the "process" probably requires a little more
thought.  In particular, how can we get the benefits of this state
diagram with the least amount of overhead?

Comments?  Suggestions?

> Christian

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available