[Debian-handbook-translators] russian translation started

Raphael Hertzog hertzog at debian.org
Wed Jun 6 09:03:13 UTC 2012


On Wed, 06 Jun 2012, Roland Mas wrote:
> > If you really want early feedback on some non-finished translation, send a
> > mail to your reviewers with a patch, or upload your branch to an external
> > repository.
> 
>   Which is exactly what's happening: multiple commits happen on the
> Github repository.

And that's fine. They can keep doing whatever they want (including merging
squeeze/master very regularly) on their repository, and never rebasing.

But when they want to push the result of their work to git.debian.org they
should push something clean.

They can prepare files on their external repository and when a given file
has been translated/reviewed, they can copy it to the checkout of official
repository and commit them. (And after that merge the official branch in
their external repository, this will work flawlessly since the content of
the files are the same).

I don't care about the precise workflow that each team decides to use. But
I care about having a clean history. And having a merge associated to each
commit, or having multiple small commits that do not represent anything
except the fact that someone worked on a chapter over multiple days, is not
what I consider clean.

> > In the end what gets pushed on git.debian.org should be clean to not
> > clutter the history.
> 
>   Again: what's wrong with one merge commit, given that it allows
> continuing working on the other repository?  Rebasing would kill history
> and force everyone using the other repository to jump through hoops.

The merge commit does not hide all the useless commits. On the contrary,
it's one supplementary commit in the history.

>   If we want a clean linear history, fine, let's just use a
> non-distributed VCS.  If we want a clean history, let's just use merges.
> But please, don't encourage people to rebase public stuff, because it
> really is a pain.

I set my requirements for what's get pushed to git.debian.org. After that,
teams are free to use the workflow that they want provided that they can
meet those requirements.

I expect the most common workflow will be to have translators working
privately on a single chapter over multiple days. When they're done, they
do a single commit, use "git pull --rebase" to ensure they're up to date
and then they push. Idem for reviews (except that you might be able to
group several chapters at once).

Another possible workflow is the one discussed above. The team works in an
external repository, and the translation coordinator manually commits
completed chapters when they're done. The branch of external respository
should never get pushed to the official repository. As part of this
manual commit by the translation coordinator, he is free to use "git
rebase -i" to clean up the history that will be pushed to git.debian.org
but that doesn't mean that the external repository has to be
rebased too. They can just continue to merge from the official repository.

Another possible workflow is that translators works on .po files and they
send completed .po files to their coordinator who commits them. Etc.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/



More information about the Debian-handbook-translators mailing list