Re: Where to merge Translations now?

[Francisco Vila]

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