[translations] Re: Where to merge Translations now?

[Francisco Vila <paconet.org@xxxxxxxxx>]

Well. Here is my list.  Carl, please, cherry-pick these commits from
lilypond/translation to stable/2.14.

There is a potential problem in a single commit: the 'LSR update'
commit could contain 2.15-only material. If you think it could break
the build or the dist, please ignore it.  Is there anything I can do
to test it?

If anything that should not be there is there, I will strip off
afterwards, I'm sorry, it's too complicated for me right now to
determine exactly what material is NOT suitable to be in stable/2.14.
Ideas are welcome, but I don't expect too much given the null feedback
my last posts had.  I blame a weird problem with a weird solution that
is also weird to explain.

After this, no new translated material should go to stable/2.14 and we
will keep translating from master unless new translation work comes
with a 'stable, please cherry-pick' label from a translator.

Thanks. I attach two files. One is a plain 'git log' output.  The
other is a bare list of the commit ids of these commits.

2011/5/5 Francisco Vila <paconet.org@xxxxxxxxx>:
> 2011/5/4 Francisco Vila <paconet.org@xxxxxxxxx>:
>> 2011/5/3 Carl Sorensen <c_sorensen@xxxxxxx>:
>>> On 5/3/11 5:45 AM, "Francisco Vila" <paconet.org@xxxxxxxxx> wrote:
>>>
>>>> 2011/5/3 Francisco Vila <paconet.org@xxxxxxxxx>:
>>>>> Hello, I have noticed that master is now 2.15; we on the
>>>>> lilypond/translation branch have unmerged work and more is to come.
>>>>> If master is now 2.15, what's the official mechanism planned for
>>>>> incorporate latest translations to the upcoming 2.12 stable?
>>>>
>>>> A possible solution is that I merge into master(2.15) as usual but I
>>>> make a list of commits for Carl to cherry-pick them onto 2.14 . Sounds
>>>> right?
>>>
>>> I would recommend that translators work from stable/2.14, rather than from
>>> master.
>>>
>>> I'm perfectly willing to have translation patches pushed to stable/2.14..
>>
>> Thanks.  Previously I need to know exactly which commit is to be
>> considered the first one to be backported.
>
> I am trying hard to find the exact commit from which we could consider
> that the translations are of 2.14-only material.  Any translation
> commit ont falling into this category should be backported into the
> stable/2.14 branch so we finally have a 'pure' 2.14 translated branch.
>
> It is very confusing to examine the history tree and try to saparate
> 2.13 translations from 2.14 translations (in all languages) and I tend
> to think that we have blindly translated all pending material without
> bothering about whether it was 2.13 or 2.14.  This is a consequence of
> having forked the master branch but not the translation branch, which
> would have been the most logical thing to do.
>
> Given that I can not parse every commit in every language and compare
> it with the original English text and decide if this has to go to
> 'stable' or 'unstable', I thought you translators could make a list of
> all your commits EXCEPT any translation whose original English text is
> in 'git log -p remotes/origin/master' and is NOT in 'git log -p
> remotes/origin/stable/2.14'. These commits should be excluded because
> they translate 2.15-only material.  All others should be backported.
>
> Basically we are looking for translated material in master that should
> not be in 2.14, if there is any.  Every other translated material
> should be manually cherry-picked into the 2.14 branch.
>
> I beg you to post such a list of commit IDs to Carl Sorensen or to me.
> A subject line like 'please cherry-pick these translation commits for
> me' would help, also.
>
> Any commit (eg. old commits) in both branches that translates material
> in 'stable' and in 'unstable' should not be in the list.
>
> Any commit IN master branch and NOT IN 2.14 branch that translates a
> mix of stable and unstable-only material in the same commit should be
> in the list; further editings to purify stable from 2.15-only material
> should follow.
>
> I am sorry for this mess and am sure that any of you could come with a
> more clever idea on how to address this situation.
>
> Now I will try to do my own list.  It it sounds too confusing and we
> do not end with a proper and useful list, don't bother. I will pass on
> the whole list of translation commits to Carl and we will address the
> cleaning afterwards.
>
>> We have a stable/2.14 branch which also contains 2.13.60 and 2.13.61 tags.
>>
>> Then, we have master and there is lilypond/translation branch on which
>> 'master' has been frequently merged.  The other way, ie merge
>> translation onto master is not clearly marked as such, maybe because
>> of my usual order of commands.  I sometimes merge master onto
>> lilypond/translation, check translations status, then checkout master
>> and merge lilypond/translation onto it. This sequence produces no
>> merge commit in master, other than previous merge master onto
>> lilypond/translation which comes from lilypond/translation branch.
>>
>> Sorry if it sounds confusing.  To summarize, it is difficult to know
>> which exact translations come before or after the fork.  IMHO a good
>> thing would have been to fork a new stable/2.14/translation branch
>> from stable/2.14 at the same time stable/2.14 was created; that way we
>> would know where we are.
>>
>> Could we still create a stable translation branch and work on it? I
>> can not work on a single branch (our current lilypond/translation) as
>> if it were two branches (stable translation + 2.15 translation), and
>> that's the current landscape.
>>
>> I could take care of porting commits from the current
>> lilypond/translation to stable/2.14/translation for my own.  Any bug
>> in this branch could never be considered a critical regression,
>> therefore it would not block stable releases, so this kind of
>> backporting is not very critical.
>
> --
> Francisco Vila. Badajoz (Spain)
> www.paconet.org , www.csmbadajoz.com
>



-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

commit bcfbe94965c118fe0b240fcede9df97aad068d22
Author: Yoshiki Sawada <sawada.yoshiki@xxxxxxxxx>
Date:   Sun May 1 11:23:40 2011 +0900

    Doc-ja: Adding two sections to NR-ja.
    
    Doc-ja:
    Adding editorial.itely and text.itely to NR-ja.
    Fixing links.
    Several small fixs.

commit d02c71f4fae62e4dcee2c79e0c2764c88cf2ce96
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue May 3 13:40:13 2011 +0200

    Doc-es: adjust versions of texidoc files.  Full update of Spanish docs.

commit 615cbf212fdaf0b220b3330da417d0c3602494f2
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue May 3 13:38:03 2011 +0200

    Doc-es: run makelsr.

commit cfddbf300bfe15bd168724ff9b802469b265c286
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue May 3 13:36:22 2011 +0200

    Doc-es: update some LSR snippets.

commit 4f29e2b1df31665625666f1bbae9c4be92ae79e6
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue May 3 13:29:24 2011 +0200

    Web-es: update NEWS.

commit b9b848fbc1085cef89a4e91fa6ab2be25de6fc37
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue May 3 13:26:13 2011 +0200

    Doc-es: update Fretted.

commit f6685e29b0140c28248d83d8690ea448604469aa
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue May 3 12:46:33 2011 +0200

    Web-es: update NEWS.

commit f5f2a103c09a0bbacac5d66093bc869dad93cf5c
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue May 3 11:26:42 2011 +0200

    Doc-es: update Fretted, Keyboards, Notation appendices, web/Introduction.

commit a35594af4584e56f6dffe15371eeca10449d1a44
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Sat Apr 30 11:04:35 2011 +0200

    Doc-es: update essay - engraving.

commit 43985acee859f999d16605ea1f4434a4f903bbb4
Author: Yoshiki Sawada <sawada.yoshiki@xxxxxxxxx>
Date:   Fri Apr 29 00:08:29 2011 +0900

    Doc-ja: adding simultaneous.itely and staff.itely.
    
    Doc-ja NR
    Adding simultaneous.itely and staff.itely.
    Changing notation.itely and expressive.itely.

commit 8b074bd0a9e57231f6ea7ac6fa4058692ecd9e15
Author: Jean-Charles Malahieude <lilyfan@xxxxxxxxx>
Date:   Thu Apr 28 15:50:06 2011 +0200

    Dof-fr: typo in keyboard

commit 2628b0725f75fdeb9fcb678c99ed414badfefd40
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Thu Apr 28 13:17:12 2011 +0200

    Doc-es: update CHANGES.

commit fb896d73c370883fca413fb15a44758b9e1efbc4
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Sun Apr 24 09:48:54 2011 +0200

    Web-es: update Manuals.

commit 192439e23bf243634b52f77dd7b084cac7a8d48c
Author: Federico Bruni <fedelogy@xxxxxxxxx>
Date:   Sat Apr 23 16:55:09 2011 +0200

    Doc-it: add Suggestions chapter of Usage (plus some fixes)

commit a96f9fb96e5a3dd0cdb0e421b78c6c94200b234a
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Thu Apr 21 17:31:47 2011 +0200

    Doc-es: update Spacing, LilyPond-Book, Running, Introduction.

commit 8acf4670cb41b50a8b01f0d83f22c2815d757b36
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Thu Apr 21 16:40:27 2011 +0200

    Doc-es: update of Percussion, Repeats, Rhythms.

commit 1fb65a6703a9e264b82c2af8421b05f8120382b9
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Wed Apr 20 20:21:51 2011 +0200

    Doc-es: update Input.

commit 8cdca637915f265d4cad1b58deeeda8c10a37ffa
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue Apr 19 11:39:27 2011 +0200

    Doc-es: updates from master.
    
    Tweaks, Ancient, Changing Defaults.

commit 4b61454c923f6b1c5ec2ccc75e1d5d2b3b281f6c
Author: Francisco Vila <francisco.vila@xxxxxxxxxxxxx>
Date:   Tue Apr 19 11:12:25 2011 +0200

    Doc-es: update CHANGES.

bcfbe94965c118fe0b240fcede9df97aad068d22
d02c71f4fae62e4dcee2c79e0c2764c88cf2ce96
615cbf212fdaf0b220b3330da417d0c3602494f2
cfddbf300bfe15bd168724ff9b802469b265c286
4f29e2b1df31665625666f1bbae9c4be92ae79e6
b9b848fbc1085cef89a4e91fa6ab2be25de6fc37
f6685e29b0140c28248d83d8690ea448604469aa
f5f2a103c09a0bbacac5d66093bc869dad93cf5c
a35594af4584e56f6dffe15371eeca10449d1a44
43985acee859f999d16605ea1f4434a4f903bbb4
8b074bd0a9e57231f6ea7ac6fa4058692ecd9e15
2628b0725f75fdeb9fcb678c99ed414badfefd40
fb896d73c370883fca413fb15a44758b9e1efbc4
192439e23bf243634b52f77dd7b084cac7a8d48c
a96f9fb96e5a3dd0cdb0e421b78c6c94200b234a
8acf4670cb41b50a8b01f0d83f22c2815d757b36
1fb65a6703a9e264b82c2af8421b05f8120382b9
8cdca637915f265d4cad1b58deeeda8c10a37ffa
4b61454c923f6b1c5ec2ccc75e1d5d2b3b281f6c