L10N migration to transifex.net

[Oron Peled]

On Monday, 21 בFebruary 2011 07:32:44 Ruediger Landmann wrote:
> On 02/21/2011 03:07 PM, Ricky Zhou wrote:
> > The reason is that since version 1.0, Transifex no longer talks directly
> > to version controls systems - instead they switched to a model where
> > Transifex stores strings in its database and project maintainers pull
> > translated strings into their own repos as part of their workflow.
> 
> This is really unfortunate: it removes one of the most useful features 
> of Transifex.

I'd like to pull this into another direction (which I'll connect with your
argument bellow).

The infrastructure team does a huge job, maintaining multitude of
systems (web, bodhi, koji, hosted, etc). One thing I didn't see at all
during the discussion before the migration is *WHY* transifex was
more painfull to maintain than other systems?

An answer to this would not only help Fedora, but also to our upstream.
because Fedora represent a use-case of big project which is *not* the
upstream. Hypothetical examples for maintenance problems:
 * Is it the data migration from version to version? (IIRC it was
    mentioned in the past as blocking/slowing upgrades) -- Than
    maybe Tx need better tooling for this.

 * Maybe many calls about "inaccessible project VCS" (as mentioned
    by Ricky elsewhere in this thread) caused a lot of churn. In that
    case, spooling commits (e.g: to a database as in newer Tx) as an
    interim storage for the data until sent to the final VCS, would
    alleviate this problem.

    [BTW: This is orthognal to the question if the project should *pull*
      from a database or the data should be *pushed* to the project
      VCS. Perhaps in the future both modes may be implemented
      (per-project selection?)]

The point I'm trying to make is that hosting Tx instance can have
another benefit to Tx -- a constant presure (and help as well) to
improve tools and methods to lower maintenance burden.

However, for this theoretical benefit to materialize, there should
be some pre-conditions
 * Just like with other Fedora software, we should be "First" and
   use/package new software versions:
   - Obviously, there's some tradeoff with stability

   - But only this way Fedora can help upstream
     (in terms of bug-reports, extra scripts, feature requests, etc)

   - F14 - transifex-0.8.0-0.2.alpha.fc14 :-(
     Rawhide - transifex-0.9.1-1.fc15 :-( :-(

 * If we cannot maintain a working up to date Tx package, this
    means it's practically orphan:
    - The gap to upstream would grow until it breaks (seems like
      that what happened)
    - Upstream would not get any benefit from this Tx instance
       and cannot effectively help us.

 * Most of the work to fix this will be on the package maintainers
    since they would need to bridge the gap between the needs/problems
    of Fedora admins and what currently Tx can provide...
    - I haven't heard them speak about the issues...

    - Maybe co-maintaining it by developers/admins would help a bit
      (short circuit requirements/problems to the fixes)

    - Involving someone from upstream (not in the on-going admin
      but in the needed fixes to make it easier) would help a lot
      both sides, but I don't know if they can invest the required time.

So, IMHO, while this thead is on the trans/docs list -- the real question
is if the 'devel' people can invest the resources to make Tx a long-term
maintainable package -- if not, than we should "outsource" this to
transifex.net (and I completely [and sadly] accept your arguments
about the dependencies it creates for Fedora -- but an orphan package
is an orphan package)

Thanks,

-- 
Oron Peled                                 Voice: +972-4-8228492
oron at actcom.co.il                  http://users.actcom.co.il/~oron
Some people claim that the UNIX learning curve is steep, but at least
you only have to climb it once