This isn't working, how can we make it better?

Richard W.M. Jones rjones at
Mon Oct 5 11:03:44 UTC 2009

On Mon, Oct 05, 2009 at 01:14:07PM +0300, Dimitris Glezos wrote:
> On Mon, Oct 5, 2009 at 1:00 PM, Richard W.M. Jones <rjones at> wrote:
> >
> > As some translators on this list are aware, I've got a few packages
> > with unmerged translation bugs going back a long way.
> >
> > I'd really like translators to be able to contribute translations
> > directly into my projects, as outlined here:
> >
> >
> >
> > and from what I hear from another project where this is done[0] it
> > seems to work really well.
> >
> > _However_ neither of the methods described above is suitable for me.
> >
> > I don't want to change the project hosting to use Fedorahosted, and I
> > cannot allow ssh access to the hosting machines from anywhere in the
> > world.
> >
> > What would really work much better is if transifex could publish a
> > git[1] repository with a rebasable branch containing the translations
> > that I could pull.  I could track this branch automatically, and merge
> > the contents in just before a release (resolving any conflicts
> > myself).
> This is something that we can't support for a few reasons:
>  1. Publishing VCSs requires a lot of work (considering the security
> work and all the VCS needed to be exposes). It also doesn't work for
> centralized VCSs.
>  2. Automatic rebase is something we can't do in Tx either. Conflicts
> will show up which Tx can't handle automatically.
> Distributed VCSs allow having branches anywhere, so one could use an
> intermediate branch on eg. github or fedorahosted instead of a
> Transifex-hosted one. In addition, this allows you to completely
> delete it if you want, do rebasing as you like, and just ask Transifex
> to 'pull a new copy'. I understand this is definitely not the same as
> having one rebasable pullable branch published by Tx, but it's a very
> good compromise offering all the benefits which at the moment are
> blockers.
> Hence, I can see two choices:
>  1. Migrate all your code somewhere where both Tx and community
> developers can have access to, and have Tx eg. push to a non-master
> branch.
>  2. Host a branch somewhere where Tx can have access to (mentioned
> above) and every now and then do an automatic `git pull`.

What I've done is to update the documentation here:

so that this third option is documented.

I'll try it and see how it goes.


Richard Jones, Emerging Technologies, Red Hat
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.

More information about the Fedora-trans-list mailing list