Policy/procedure to pull work from mainline to 1.8 branch?

Derek Atkins warlord at MIT.EDU
Tue Feb 4 10:54:06 CST 2003


In order to maintain stability of the 1.8 branch we should have some
sort of policy/procedure for when to pull changes from the mainline up
into the branch.  In particular, I would hope that people plan to do
development on the mainline, not on the 1.8 branch..  And then we can
pull completed work/bug-fixes/etc. onto the branch once they are
sufficiently tested.

For example, I just fixed a qif-importer bug on the mainline, which
should eventually be pulled onto 1.8, but I don't want to pull it down
until there is more testing..  What constitutes that?  What kinds of
discussions should we have about other changes to the release branch?

Just the little bit of release-engineer in me talking....

       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 mailing list