Minutes from the Fedora L10N coordination meeting

[Jared K. Smith]

On Thu, Feb 17, 2011 at 9:49 PM, noriko <noriko at fedoraproject.org> wrote:
> My concern has to move to an exit plan.
> Two +1s stated to have an exit plan as the condition of 'yes' in the
> meeting. Could you please advise the procedure to implement an exit plan
> when we are ready a resource for us?

As is always the case in Fedora, we're fairly flexible in our ability
to move to the best solution that's available at that moment in time.
As far as the short-term goes, the only reasonable exit plan I can see
would be to move back to a self-hosted version of Transifex, or to
move to another solution.

As I've explained before, we don't have the necessary manpower to keep
our self-hosted version of Transifex up and running well.  Even if
someone were to come along and offer to help, I think our
Infrastructure team would be hesitant to move back to a self-hosted
solution without a very strong long-term commitment of dedicated
resources to not only keep the instance running, but to keep it up to
date (both in terms of features and bug-fixes).

An analogy I like to use is that software is like an animal.  If my
daughter came to me today and asked for a pony, what would my reaction
be?  My first thoughts would be to think about food, a place for it to
live, how to clean up after it, the costs involved, etc.  I think we
should take that same sort of attitude with the software we bring into
Fedora Infrastructure.  It's easy to get software up and running, but
it's an entirely different different matter to be dedicated to the
long-term maintenance of the software package.

The only other exit strategy I see is theoretical.  If at some future
date there's software available that's better than Transifex and the
advantages of moving to that software justify the transition, we could
always move to it.  But like I said, it's theoretical.  Right now,
Transifex is by far the best solution that I've seen for the type of
translation we're doing in Fedora.  I have full confidence both in the
Transifex team's technical abilities and in their willingness to
listen to open source communities (like Fedora) and add features as
necessary.  So, to be blunt, I don't see us moving away from Transifex
in the short term, but it's always a theoretical option in the future.

On a more technical nature, the only realistic exit strategies would
be to either roll back to our current hosted instance of Transifex
(and be willing to live with the old version), or find a team willing
to both install a newer version of Transifex internally *and* take on
the long-term maintenance of that instance. The first is a short-term
solution at best, and the second takes more resources that we have
available.

Let me also point out that most of the pain of this migration to
Transifex.net is not actually involved in the move to Transifex.net
itself, but in the upgrade from version 0.7 to the 1.0 version.

> It is best for us to get the system back on home Fedora.

In general, yes, one could argue that having Fedora being self-hosted
from an infrastructure standpoint is better.  But we've also got to be
open-minded enough to realize that each additional tool we add to our
own infrastructure comes with a maintenance burden (or a technical
debt, as some people prefer to call it).  One of my jobs as the Fedora
Project Leader is to work with all the teams involved to help balance
our wishes with our resources, and try to make the best decisions I
can for Fedora as a whole.  In the case of the migration to
Transifex.net, it's pretty clear that the advantages outweigh the
risks.  Why can I say that so confidently?  It's because I've watched
the Transifex team as they've developed the software, turned it into a
small business, and continued to do the right thing.

Hopefully, that clarifies things.

--
Jared Smith
Fedora Project Leader