Backporting

John Ralls jralls at ceridwen.us
Thu May 19 12:24:32 EDT 2011


On May 19, 2011, at 8:29 AM, Derek Atkins wrote:

> 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.

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



More information about the gnucash-devel mailing list