Notification mails for git repos

Derek Atkins warlord at MIT.EDU
Thu Jan 31 10:04:20 EST 2013

Geert Janssens <janssens-geert at> writes:

> Daggy fixing is probably not the only useful scheme though. I could
> also imagine something like this to work:
> - all bugfixes and only bugfixes happen on the 2.4 branch
> - the 2.4 branch regularly gets merged into the development branch, so
> all bugfixes also will end up in future releases
> This concept is no longer back-porting, but
> forward-porting. Advantage: all bugfixes eventually end up in the
> active trees and git branches show the history, no need for BP->AUDIT
> Note that neither daggy fixing nor forward porting are possible as
> long as we're tied to svn. So this discussion is on future process,
> not practical next steps yet.

Techncally we could do the "all bugfixes go into release; frequently
merge release back into trunk" method.  The downside is that larger
"fixes" dont get tested as much before going into the release.

> How can we in the future improve our process to something in which the
> history clearly reflects what actually happened, in which no work is
> lost (by forgetting to backport) and without too much overhead.

And also test/review changes before they go into the release branch?

> Geert


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

More information about the gnucash-devel mailing list