On May 19, 2011, at 8:29 AM, Derek Atkins wrote: > John Ralls <jra...@ceridwen.us> writes: > >> On May 18, 2011, at 11:32 AM, Christian Stimming wrote: >> >>> Am Mittwoch, 18. Mai 2011 schrieb Derek Atkins: >>>> John Ralls <jra...@ceridwen.us> writes: >>>>> Is there a catch-all bug for 2.4 backporting? If not, should there be, >>>>> or shall we just handle our own backports and not worry about it? >>>> >>>> There is not, but we could certainly create one. >>> >>> Exactly. >>> >>> On another note, I don't think we have yet found again a useful workflow >>> for >>> back-porting. Marking bugs as dependent on some arbitrary bug number used >>> to >>> be a somewhat annoying step in the past for me. On the other hand, the "BP" >>> marker in the commit message gets forgotten easily, too. I don't know, too. >>> >> >> Yeah, I know we *can* create one. The question is *should* we create one, or >> should we use some other method of tracking the backports... or maybe not >> bother? ISTM the simplest solution is to just double commit (trunk and 2.4) >> when doing a bug fix. >> >> Is there supposed to be an email for a "BP" commit beyond the [Audit] >> notation in gnucash-changes? > > No. It's just the audit notation. The idea at the time was that it > would stand out and draw attention to get other eyes on the changeset. > It was also an idea that we'd let the changeset "bake" a bit before > backporting, because we wanted to be fairly sure the change was > "correct" before it possibly infected the "stable" tree. So that's an > argument against the double commit (you don't get a chance to bake the > changes before it hits stable). > > 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? Regards, John Ralls _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
