annoyingly rounding off

[Mike Alexander]

--On January 29, 2013 12:40:06 PM +0100 Geert Janssens 
<janssens-geert at telenet.be> wrote:

> 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

OK, thanks for the explanation.  I was hesitant because of the comment 
Derek made in a message in December that the BP had to be on a line by 
itself for the magic to happen.  I didn't know what magic was invoked 
by the BP and didn't want to mess things up since I hadn't invoked it.

I backported r22673 to the 2.4 branch.  I think I followed your 
instructions correctly.  I used git to do it so the push was done using 
"git svn dcommit".  I hope that was correct, it looks like it did the 
right thing.

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

OK, I had noticed that there hadn't been any checkins for several days 
and thought that might be because of the upcoming transition.

I checked in my other two changes, but I think I'll hold off 
backporting them, at least until they've been in for a while.  They are 
probably ok to backport, but the bugs they fix are somewhat less 
critical and the changes are somewhat less trivial.

           Mike