Git translation branch policy change: merge with and from stable/2.16

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

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/10/20 David Kastrup <[hidden email]>:
>
> If it is ok with people, I'd propose the following course in order to
> get the ball rolling again:
>
> I'll merge stable/2.16 into translation.  That should be unproblematic.
> Then I'll merge translation into staging.  This will require a bit of
> cleanup and conflict resolution.

The only problems I foresee, will come from original English docs. As
we have not translated anything new since the fork, all translated
material is directly dumpable there. Not blindly, though, you know
what I mean.

> I am willing to take care of that and of the translation merges into
> staging when translation is still based on stable.

How is this useful? Here I can see a clear need of two translation
branches. It translation is based on stable, we can not work on devel
branch.

> Since one purpose of
> getting staging up to date with regard to translations is to be able to
> do extensive convert-ly work, the merging might be a bit tricky until
> things move over completely.

My proposal is to move to devel branch, merge master on translation
and forget about stable.  We have been freezed for too long. Not a
line of any new material in devel releases has been translated.

> I am not sure when translators will want to move their focus to master
> rather than stable again: it might be possible to create a branch
> translation-stable for working on stable branch translations, but I
> would like to phase out stable branch work eventually and so a separate
> translation-stable can still be left for a time when we feel we really
> need it.  Probably cherry-picking will be enough if commits for
> unstable-only material are kept separate well enough.

Agreed. But specifically, you mean cherry-picking
translation-->staging or translation-->stable?

> At any rate, with this plan it is more or less up to the translators to
> decide when they think 2.16.1 is ready.  There is not much I
> cherry-picked into the stable branch since the last translation merge,

I think nothing has been, for the translations' sake

> and I'd not like to wait much longer than a week for 2.16.1 in
> consequence, but 2.16.2 will likely take quite longer.
>
> People fine with that?

The question is: translators, do you plan to update yet something for
stable? whe we are reasonably done with stable, let's forget it and
move to staging.

As for Spanish, I am done. Can not speak for others.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Jean-Charles MALAHIEUDE
Le 20/10/2012 20:33, Francisco Vila disait :

> 2012/10/20 David Kastrup <[hidden email]>:
>>
>> If it is ok with people, I'd propose the following course in order to
>> get the ball rolling again:
>>
>> I'll merge stable/2.16 into translation.  That should be unproblematic.
>> Then I'll merge translation into staging.  This will require a bit of
>> cleanup and conflict resolution.
>
> The only problems I foresee, will come from original English docs. As
> we have not translated anything new since the fork, all translated
> material is directly dumpable there. Not blindly, though, you know
> what I mean.
>

I think you mean all @lilypond that might have changed in-between?

>> I am willing to take care of that and of the translation merges into
>> staging when translation is still based on stable.
>
> How is this useful? Here I can see a clear need of two translation
> branches. It translation is based on stable, we can not work on devel
> branch.
>

That's what I feared since the freeze: having to maintain two sets of
translations.

>> Since one purpose of
>> getting staging up to date with regard to translations is to be able to
>> do extensive convert-ly work, the merging might be a bit tricky until
>> things move over completely.
>
> My proposal is to move to devel branch, merge master on translation
> and forget about stable.  We have been freezed for too long. Not a
> line of any new material in devel releases has been translated.
>
>> I am not sure when translators will want to move their focus to master
>> rather than stable again: it might be possible to create a branch
>> translation-stable for working on stable branch translations, but I
>> would like to phase out stable branch work eventually and so a separate
>> translation-stable can still be left for a time when we feel we really
>> need it.  Probably cherry-picking will be enough if commits for
>> unstable-only material are kept separate well enough.
>
> Agreed. But specifically, you mean cherry-picking
> translation-->staging or translation-->stable?
>

I think what should be done is
   translation synchronizes with staging
   translation-stable synchronizes with staging/x.y

so, there would be
1- one merry-go-round: staging->master->translation->staging
2- cherry-picking from master towards stable when needed
3- one merry-go-round stable <--> translation-stable

>> At any rate, with this plan it is more or less up to the translators to
>> decide when they think 2.16.1 is ready.  There is not much I
>> cherry-picked into the stable branch since the last translation merge,
>> and I'd not like to wait much longer than a week for 2.16.1 in
>> consequence, but 2.16.2 will likely take quite longer.
>>
>> People fine with that?
>
> The question is: translators, do you plan to update yet something for
> stable? whe we are reasonably done with stable, let's forget it and
> move to staging.
>
> As for Spanish, I am done. Can not speak for others.
>

I just updated the searchbox before having some visitors yesterday.
Everything is up to date on my side for 2.16.

One might check the result of a po-replace before releasing.

I'll be on vacation between nov. 5 and 11 (except one day for my
mother's 80th birthday).

Cheers,
Jean-Charles


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Jean-Charles MALAHIEUDE
Le 21/10/2012 13:15, David Kastrup disait :

> Jean-Charles Malahieude <[hidden email]> writes:
>> That's what I feared since the freeze: having to maintain two sets of
>> translations.
>
> I think that we will likely leave the stable branch behind soon with
> regard to documentation maintenance.  Our documentation is improving all
> the while, and much of it remains applicable to the stable branch.  At
> the same time, there are several significant changes going forward, and
> those will affect a large ratio of documentation, partly
> semiautomatically, meaning that cherry-picking changes without extensive
> merge conflicts will get harder and harder.
>
> It is important for us to work on documentation designed to match
> ongoing work, cater for the future of LilyPond rather than its past.  We
> don't have two separate teams maintaining stable and unstable branches
> (in fact, it is a conflict of interest that I am still responsible for
> the stable branch).  So I don't really see much of an alternative to
> focusing documentation improvements, even where they tend to apply
> equally well to past versions, on master.  If we have master the best
> and most consistent we can make it, this will end up in a stable release
> after all.  Not 2.16, but 2.18.
>

Fine with me.

> So I really think we should move translations over, and live with the
> documentation of 2.16 being the best we could make it for 2.16.
>

Do we translators first update what you just merged from stable? I'm on
it at the present (my wife is conducting a choir rehearsal of King
Arthur this afternoon).

Cheers,
Jean-Charles


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Federico Bruni-2
2012/10/21 Jean-Charles Malahieude <[hidden email]>:
>> So I really think we should move translations over, and live with the
>> documentation of 2.16 being the best we could make it for 2.16.
>>
>
> Do we translators first update what you just merged from stable? I'm on it
> at the present (my wife is conducting a choir rehearsal of King Arthur this
> afternoon).

Yes, please wait for the update (at least from me).
Then we can move to 2.17, I agree.


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
In reply to this post by Francisco Vila
2012/10/20 Francisco Vila <[hidden email]>:
> As for Spanish, I am done. Can not speak for others.

Because of the backportings I have updated some files and I'd like to
do a couple more of editings, namely on Input and Rhythms. It will
probably take two days. After that, I am completely done with Stable.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com


Reply | Threaded
Open this post in threaded view
|

Re: Git translation branch policy change: merge with and from stable/2.16

Francisco Vila
2012/10/22 Francisco Vila <[hidden email]>:
> 2012/10/20 Francisco Vila <[hidden email]>:
>> As for Spanish, I am done. Can not speak for others.
>
> Because of the backportings I have updated some files and I'd like to
> do a couple more of editings, namely on Input and Rhythms. It will
> probably take two days. After that, I am completely done with Stable.

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


12