Le dimanche 12 août 2012 à 14:48 +0200, David Kastrup a écrit :
> Documentation improvements are still admissable, documentation rewrites
> not necessarily as we want to avoid significant changes between the
> English documentation and reasonably well-maintained translations. I
> have no clear view regarding finalizing of the translations.
As long as no documentation significant rewrite reaches master,
finalizing translations of the documentation may be done by
cherry-picking commits from translation branch; would you like to do or
On the contrary, if big doc changes reach master before 2.16.0 is out, a
new branch translation-2.16 should be created, that would be merged into
and from stable/2.16 the same way as translation and master/staging,
with some extra care deserved by stable/2.16; if there is the need for
it, I could handle this, having in mind that checking "make dist" is
currently a PIOA (i.e. a pain for all of us).
I've sent an update request to the Translation Project with 2.15.95
release (with [hidden email] in CC), so within a week we
should get numbers of PO files to check in in master and stable/2.16.
Le lundi 13 août 2012 à 10:55 +0200, David Kastrup a écrit :
> I haven't really tracked translations so far, so my own level of
> suitability here is pretty close to zero, modulo non-task-specific
> computer expertise (which some people deem sufficient for making me
> useful for Windows support, a system I have successfully avoided for
> decades). In other words, I'd be happy to delegate, but we are not
> likely to have the help of patchy-staging for it. Stuff has to be
Well, the first instance of Patchy's translation branch build I put up
on Grenouille was broken (it tried to create and build a fast-forward of
master from translation), I think I fixed it (as well as the general
case of building any branch other than staging), and last build seemed
to work, I'll likely push Patchy changes on Wednesday; this periodic
build should give an additional hint about the state of translation
If I handled backporting translation updates, I would create
translation-2.16 branch on central repository on Savannah, with the
policy to allow history rewriting on that branch, I would rebase it on
stable/2.16, ask translators to work on a separate branch checked out
from stable/2.16 (but that would never get pushed except something like
dev/translator-name), apply patches from emails or cherry-pick from
dev/translator-name on translation-2.16, build this branch with
Patchy and if Patchy is successful fast-forward stable/2.16 to
translation-2.16, and repeat the process once (or if necessary twice) a
> I am clueless in that area, so it will be good if you kept track of what
> was required here.
Paco has announced to be on vacation and mostly offline until Friday, so
Jean-Charles and I took this task -submitting to the TP) over from him,
to give translators roughly two weeks for submitting POs for 2.16.
> I think we have a reasonable chance to be in the
> same room with Graham when releasing 2.16 if things go well.
In the meantime, cross fingers, and more importantly let's trim hard on
those bugs :-)
Il giorno lun, 13/08/2012 alle 16.21 +0200, David Kastrup ha scritto:
> If I handled it, I would try cherry-picking and praying. If your
> proposal is in your comfort zone, I'd not mind letting you handle it.
> However, I am not sure that the typical translator will understand what
> is expected of him, so I would guess that you'd likely be working more
> with commits on the main translation branch than your plan calls for.
I finally remember how we managed translation branch when I was
translation meister (IIRC I did this for at least one of 2.10 and 2.12
releases): translation branch was no longer merged with staging and from
master, but with and from the latest stable branch; then, when
documentation changes or backports ceased on that stable branch or a
limited goal of documentation to be translated was reached, translation
changes were backported to master, and finally the translation branch
got reset (deleted and recreated, actually) to master. As nobody seems
to have merged translation from master since
952705bbbb000581a13836e6a733df04511e93c5, which precedes
release/2.15.95-1, I favour this plan.