Where to merge Translations now?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Where to merge Translations now?

Francisco Vila
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?

Thanks.

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


Reply | Threaded
Open this post in threaded view
|

Re: Where to merge Translations now?

Francisco Vila
2011/5/3 Francisco Vila <[hidden email]>:
> 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?

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


Reply | Threaded
Open this post in threaded view
|

Re: Where to merge Translations now?

Francisco Vila
2011/5/3 Graham Percival <[hidden email]>:

> On Tue, May 03, 2011 at 01:45:09PM +0200, Francisco Vila wrote:
>> 2011/5/3 Francisco Vila <[hidden email]>:
>> > 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 guess so.
>
> Do we really need those updates, though?  I mean, that will be a
> lot of commits to cherry-pick.  And it'll be much worse when
> translators start using 2.15-only features in their translations;
> backporting any commit with those will break the stable/2.14
> build.

We could already have translated 2.15-only material, but we don't know
when a material is 2.15 only, so we have probably mixed 2.14 and 2.15
translations in the same commits, making a separation very difficult.
I will assume that changes in originals prior to the fork are 2.14 and
translations of these will be cherry picked if I can extract them.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Where to merge Translations now?

Francisco Vila
In reply to this post by Francisco Vila
2011/5/3 Carl Sorensen <[hidden email]>:

> On 5/3/11 5:45 AM, "Francisco Vila" <[hidden email]> wrote:
>
>> 2011/5/3 Francisco Vila <[hidden email]>:
>>> 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.

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


Reply | Threaded
Open this post in threaded view
|

Re: Where to merge Translations now?

Francisco Vila
2011/5/4 Francisco Vila <[hidden email]>:

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


Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>:

> 2011/5/4 Francisco Vila <[hidden email]>:
>> 2011/5/3 Carl Sorensen <[hidden email]>:
>>> On 5/3/11 5:45 AM, "Francisco Vila" <[hidden email]> wrote:
>>>
>>>> 2011/5/3 Francisco Vila <[hidden email]>:
>>>>> 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 (5K) Download Attachment
ltr-bare.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Where to merge Translations now?

Francisco Vila
2011/5/12 Carl Sorensen <[hidden email]>:

>
>
>
> On 5/10/11 1:30 AM, "Francisco Vila" <[hidden email]> wrote:
>
>> Well. Here is my list.  Carl, please, cherry-pick these commits from
>> lilypond/translation to stable/2.14.
>
> I have cherry-picked the commits.  I'm a bit concerned that
> Documentation/es/changes.tely may be wrong as a result of some merge
> conflicts I had.  Can you please check that?

Sure, I'll do it. Thanks,

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


Reply | Threaded
Open this post in threaded view
|

Re: Where to merge Translations now?

Francisco Vila
In reply to this post by Francisco Vila
2011/5/12 Carl Sorensen <[hidden email]>:

>
>
>
> On 5/10/11 1:30 AM, "Francisco Vila" <[hidden email]> wrote:
>
>> Well. Here is my list.  Carl, please, cherry-pick these commits from
>> lilypond/translation to stable/2.14.
>
> I have cherry-picked the commits.  I'm a bit concerned that
> Documentation/es/changes.tely may be wrong as a result of some merge
> conflicts I had.  Can you please check that?

It looks as if you applied two patches in reverse order.  It is my
fault, because I put the same info line on both of them (namely
'Doc-es: update CHANGES').  One is from 2011-04-19 and other from
2011-04-28.  Now they are in the stable/2.14 branch but the 2011-04-28
is now older in history than 2011-04-19, which is latest in history.

Aside of how could you manage to do this, the fact is that the
resulting es/changes.itely file looks in perfect sync with English
changes.itely file of the same stable/2.14 branch, so finally I think
there is no problem at all.

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