John Ralls <jra...@ceridwen.us> writes:
>> We don't really have a good procedure in place.
>
> Well, let's work one out then.
>
> It's easier to write a procedure if one starts with goals for the
> procedure to accomplish, and the first goal is obvious: To get
> bugfixes into the next release. I think a more formal statement of
> your "baking" analogy is to get bugfixes tested before committing them
> into the stable branch. Any more?
* We want to make sure we don't forget changesets (which I suppose is a
corellary of your first statement.
* We want to make sure we don't commit extra changesets (no desire to
add additional cruft to the stable branch)
* We want to keep the stable branch, well, stable. In a commercial
environment I would say that perhaps we should require a "make check"
test that shows the bug and then the patch that fixes it, so we don't
have a future regression?
* It would be nice to actually have the code audited before committed,
in addition to it just being tested. (This is why 'BP' -> "AUDIT")
I'll try to think of more....
> Regards,
> John Ralls
-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
warl...@mit.edu PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
