annoyingly rounding off

Geert Janssens janssens-geert at telenet.be
Tue Jan 29 06:40:06 EST 2013


On 27-01-13 19:16, Mike Alexander wrote:
> On Jan 26, 2013, at 9:11 PM, Mark Smith <gnucashorg at awayand.sleepmail.com> wrote:
>> Apologies for the late response. Yes, indeed, that sounds exactly like
>> my problem! Do I need to do anything to ask for backporting this to 2.4?
>> Thanks a lot!
> I didn't mark this commit for back porting when I checked it in, and I don't know what needs to be done now to get it back ported.
Whether a commit was marked for backporting is not so important. That 
corrently only serves as a visual reminder for other developers to be 
aware that the commit is to be backported. There used to be a release 
manager that ultimately decided if it was ok or not and actually 
performed the backports. That role is not in our process anymore.

Generally, any commit can be backported if it
- fixes a bug (new features shouldn't be backported)
- is fairly trivial to do so
- doesn't introduce new or changed translatable strings

I believe your commit fits all of the above criteria, so feel free to 
actually backport it. You can do this by
- checking out the 2.4 branch and applying the same changes there 
(pretty easy with git cherry-pick).
- Then change the commit message (eg. with git commit --amend)
    * it should start with [orig-rev] (in your particular example: [22673]).
    * remove the line holding BP (if it exists)
    * remove the line referring to the original svn commit (only there 
when working in a git repo)
- Push the commit
> I have some other changes in this area ready to be checked in when the transition to the new source code control setup is complete.  They aren't as important, but could also be back ported if people think it's safe enough to do so.  These changes make GnuCash recalculate the fraction when the account in a split is changed (so, for example, if you change a split from a JPY account to a USD account you can enter dollars and cents) and make the calculation of the fraction more nearly agree with the way data is actually entered in splits.
You don't have to wait for the transition really.

The root repository will be unchanged before and after the transition 
(svn). So your changes won't get lost. The new git repo will fetch them 
from the same svn base repo as the current one as soon as they are 
committed.

As for backporting those changes: you can apply the same rules as 
mentioned above to determine whether the changes should/could be backported.

Geert


More information about the gnucash-user mailing list