Re: Where to merge Translations now?

[Francisco Vila]

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 <address@hidden>:
> 2011/5/4 Francisco Vila <address@hidden>:
>> 2011/5/3 Carl Sorensen <address@hidden>:
>>> On 5/3/11 5:45 AM, "Francisco Vila" <address@hidden> wrote:
>>>
>>>> 2011/5/3 Francisco Vila <address@hidden>:
>>>>> 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

ltr.txt
Description: Text document

ltr-bare.txt
Description: Text document