Notification mails for git repos
warlord at MIT.EDU
Thu Jan 31 10:04:20 EST 2013
Geert Janssens <janssens-geert at telenet.be> 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?
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
More information about the gnucash-devel