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

[ Thread Index | Date Index | More lilynet.net/translations Archives ]


2012/9/25 David Kastrup <dak@xxxxxxx>:
> Obviously, documentation improvements concerning 2.16-only material are
> quite eligible as they will not disrupt 2.16 operation and compatibility
> itself.  One just needs to be careful with stuff concerning manual
> structure, web functionality etc in order not to render the manual
> inconsistent.
>
> If somebody volunteers to do this selection process (possibly also
> committing to the 2.16 stable branch) instead of me, it will certainly
> save me some work.

At first, I can not see what amount of translation work already in
2.16 is _not_eligible to be cherrypicked to staging right now and
become a part of the 2.17 releases. Possibly all that currently is in
translation and was not there before the 2.16 fork, could equally be
in staging.

The reason being that translators do not have a reference of what new
material is in 2.17 and therefore we'll translate from the latest
stage of translation, and that is 2.16.

New 2.17 translation work can not be pushed to translation branch
until we close the door to 2.16 because we don't have a translation
branch for unstable which is distinct of that we have for stable. Or,
do we? I think we should. For 2.18, I respectfully demand to fork
stable and its own translation branch at the same time. With our
current system, translations of the few first 2.17 releases are
outdated and there is no easy possibility of updating them, other than
pushing directly to staging.

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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/