janssens-geert at telenet.be
Sun Oct 28 12:57:07 EDT 2012
On 29-09-12 11:54, Cristian Marchi wrote:
> I'm currently working on the bug you pointed out and I hope to have it
> finalized and translated to Italian in some days. I will let you know
> when I'm done. Thanks for waiting for me again!
> The patch for that bug will apply to 2.4 and trunk. Can you please
> give me advice on how to proceed? Do I have to apply it to trunk first
> and then to 2.4 or the other way around? How do I write the commit
> message for backporting?
I don't remember having seen a reply to these questions. In general,
changes should first be applied to trunk and then backported to 2.4. At
least if the change is also relevant for 2.4.
The commit message for trunk should contain a line with only "BP" on it
to indicate this commit is meant to be backported. That helps to check
later if all the relevant commits are really backported. It also alters
the commit messages that are sent to gnucash-patches and gnucash-changes
to begin with "AUDIT". There used to be a release manager once that
decided on whether a patch should be backported or not and the AUDIT/BP
marks were meant as a request to backport. The marks were the release
manager's clue to start evaluating a patch for backporting. This
function no longer officially exists and nowadays each contributor
backports his own patches. But the AUDIT/BP marks are still useful for
other Developers to follow what gets backported and what not.
The commit message on the commit that goes into the 2.4 branch
essentially uses the same text with one small change: the line
containing the BP mark is removed, and instead the revision number of
the trunk commit is prepended to the message, surrounded with square
An example will probably make it much clearer.
The commit to trunk would have this message:
My latest changes
Let's assume this got committed in r22445 and now has to be backported.
The message to use on the 2.4 branch will now be:
 My latest changes
More information about the gnucash-devel