resolving i18n merge conflicts, is there a policy fot i18n commits?

[Thomas Lübking]

Am 16.03.2012, 19:35 Uhr, schrieb Martin Gräßlin <mgraesslin at kde.org>:

> On Friday 16 March 2012 19:23:18 Oswald Buddenhagen wrote:
>> On Wed, Mar 14, 2012 at 08:53:07AM +0100, Thomas Lübking wrote:
>> > Am 14.03.2012, 08:40 Uhr, schrieb Oswald Buddenhagen <ossi at kde.org>:
>> > >On Tue, Mar 13, 2012 at 11:45:56PM +0100, Thomas Lübking wrote:
>> > >>Is there any policy on i18n commits/conflicts, ie. like only 4.8 is  
>> up
>> > >>to
>> > >>date (seems to me?) so one can safely
>> > >>git merge -Xtheirs origin/KDE/4.8
>> > >
>> > >what exactly are you merging?
>> >
>> > kde-workspace, local KDE/4.8 -> local master
>> > resolved merge i18n conficts "-s ours" from origin/KDE/4.8, then  
>> merged
>> > local KDE/4.8 into local master
>> >
>> > wrong?
>>
>> utterly. only kdelibs is merged 4.8 => frameworks. everything else is
>> cherry-pick. as always has been.

Well, i was told different (not by martin, btw.) to avoid additional  
commits. *shrug*

> That's news to me :-) At least I have been merging from 4.7 to master in  
> kde-workspace till scripty made it impossible and I have been merging  
> all my
> commits from 4.8 to master. And looking through the commits I'm quite  
> sure that others do merge as well.

I do absolutely not mind whether to merge or c-p, to back- or forwardport  
- but maybe there should be some definite official statement?
Like eg. about here:  
http://techbase.kde.org/Development/Git#KDE_Git_Policies

where the current policies helpfully read:
"KDE policies on Git. More generic development policies go elsewhere."

Cheers,
Thomas