Christian Stimming <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
