pushing to branches imported from git

[chrysn]

projects that are based on git and want to use lp for translations) are currently left with two options: either download manually at given points in time (which is cumbersome), or open up their own local bzr-git clone of their git repo, push that to lp, and have lp translations write back there.

(sorry if i'm using git lingo here for bzr -- i'm not familiar with bzr at all, but quite so with git.)

a solution could be to enable write access to branches that were imported from git. bzr-git supports pushing back locally ("dpush"). this would require launchpad to identify to the server as using its own ssh key, which would have to be published accordingly. user names are not an issue as they can be encoded in the git url.

concerning security: technically speaking, this is no more insecure than using translations with bzr. sofware authors shouldn't blindly pull from where they allow launchpad to push just as they shouldn't blindly pull from launchpad's bzr hosting without thinking (just in case launchpad is compromised).

concerning shared hosters like gitorious or github: in order to ease things for software maintainers, launchpad could register accounts there, so maintainers could grant that launchpad user write access to the respective branches -- transifex did it like this back in the days when they had support for version control. (to be honest, i only looked at launchpad's translation support because transifex got far less usable when they dropped vcs support). of course, this is not required -- users could just as well add a user "my_username-launchpad" and assign the published ssh public key of launchpad.

implementing this feature would allow projects that use git for source code management to integrate fully with launchpad without having to start to use two vcs tools.

[Данило Шеган (danilo)]

A related bug is bug 651844, where we'd make all the bzr branches available through git. I know there was desire to make this work, but it's a non-trivial thing to do.

As far as translations goes, while Launchpad can not commit translations to your external repository directly, it was always my impression that maintainers would not be very eager to let other tools have an option of directly committing to a repository. I was hoping transifex would have turned into a project providing a server side, usually hosted by the project maintainers and defining policy, and a protocol for submitting translations. In such a case, Launchpad would have implemented this protocol and could talk to any of the servers. Maintainers would be able to define strict policy on the server side knowing that it's them who are controlling what can be modified in their repositories, and not giving full access to external sources. Alas, this was not to be :)

Anyway, for the time being, I'd propose using Launchpad in the following way to make things as automated as possible for you:
 1. Get your git branch imported into LP
 2. Set up translation imports from that branch in LP
 3. Set up translation exports to a separate branch in LP, perhaps even entirely empty otherwise (translation exports are done once a day if there are any changes)
 4. Run cronscripts on your side that do something as simple as "bzr branch lp:~your/export/branch bzr-branch && cp bzr-branch/po/*.po your-git-trunk/po && cd your-git-trunk && git commit -m 'Merge translations from LP.'".

This would basically implement a policy on your side (i.e. "copy only po/*.po files"), thus restricting the damage Launchpad could do. Even though Launchpad is generally very smart about merging translations between several sources, you could also do more magic with msgmerge instead of just copying files, but that's also part of the policy that would be specific to your project.

Of course, you'd usually want to run this on an always-on machine and unattended, so it might be nice if there was service providing it. But, I believe this will allows you an easy way to automate stuff with Launchpad already.

[chrysn (chrysn)]

from my point of view, exposing all bzr branches via git would completely solve the problem -- i wouldn't have let it push to the main branch anyway, and can track a remote git branch with my "translations review for merging" just as well.

i can't speak for other vcs (i suppose that approach won't work for the non-distributed svn and cvs), but from the git point of view i'd declare this bug a duplicate of bug 651844.