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@xxxxxxxxxxxx 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
--
docs mailing list
docs@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/docs
