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,