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

[David Kastrup]

Jean-Charles Malahieude <address@hidden> writes:

> Le 20/10/2012 20:33, Francisco Vila disait :
>> 2012/10/20 David Kastrup <address@hidden>:
>>>
>>> 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.

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.

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.

-- 
David Kastrup