Backporting

[Derek Atkins]

John Ralls <jralls at ceridwen.us> writes:

> On May 18, 2011, at 11:32 AM, Christian Stimming wrote:
>
>> Am Mittwoch, 18. Mai 2011 schrieb Derek Atkins:
>>> John Ralls <jralls at 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.

> 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
       warlord at MIT.EDU                        PGP key available