On 02/21/2011 04:10 PM, Ricky Zhou wrote:
On 2011-02-21 03:25:23 PM, Ruediger Landmann wrote:
> As I see it, you answer your own question further down your post. We
> lose control of the instance. Whether or not the Fedora project ever
> exercises that control is a different matter.
>
> Some people might see this as a purely theoretical distinction, but it's
> a distinction that exists at the very heart of Free software. With the
> exception of packages that I'm involved in maintaining, I have very
> rarely delved into the code or modified the code of the Free software
> that I use every day. However, by choosing Free software, I retain the
> ability to do these things if and when I choose to do so.
transifex.net runs on the same open source software that we run (albeit
a much newer version). If we ever have the need to exercise control
over the instance that
transifex.net won't allow us, then we are always
free to move back to running our own instance (the migration would work
exactly like the one that's currently ongoing).
I'm sorry -- I didn't express myself clearly enough here, since both you
and Jared have both understood something a little different from what I
meant.
I know that Transifex is indeed Free software, and I certainly didn't
mean to imply anything different. The parallel I'm drawing is this:
* Free software on my PC means that I can inspect or modify that
software, whether or not I ever exercise that power.
* The Fedora Project's control of its own translation infrastructure
means that we can inspect or modify that infrastructure, whether or not
we ever exercise that power.
That's why I said the situation is analogous -- it's certainly not
identical.
> More pragmatically, needing to move translation files between
>
transifex.net and our repos seems to me like an unfortunate hurdle to
> translations in Fedora. This is probably not a substantial disadvantage
> to relatively stable software packages where there is little change from
> version to version, but would be felt more in documentation where string
> changes are more frequent.
As we discussed in the other sub-thread, this change happens regardless
of whether we run 1.1 in Fedora or on
transifex.net.
I stand corrected on this point; but see below. Please take everything
I say in the friendly and collegiate spirit in which it's intended.
Line-by-line rebuttals inevitably come across as sounding quarrelsome,
and that's not my intention at all. I've tried to keep that tone out of
my responses, but if any has inadvertently slipped through, please
forgive me :)
I consider this to
be a huge improvement for the following reasons:
Sysadmin:
- Don't have to manage shared storage when scaling transifex to run on
multiple servers. In Fedora Infrastructure, this is one of the
things we've been looking forward to the most with moving off of
Transifex 0.x.
- Don't have to worry about maintaining and securing private SSH keys
with access to a bunch of upstream projects. Right now, we have to
enter passphrases every time we restart a server with Transifex (and
whenever we forget, the site is just broken for translators), and we
also have to worry about securing a bunch of SSH keys to things that
we'd rather just not have access to.
I have not been involved in maintaining the Transifex instance, so I'm
not in a position to dispute these points.
Developer:
- I don't have to give Transifex or translators write access to my
repo. Sure, access can be restricted with commit hooks or a file
whitelist in Transifex, but those are a pain to maintain.
It's also a pain to have to remember to pull files manually and to have
to maintain a configuration file. With the previous system, you set up
the pseudo-user once and never had to think about it ever again. This
made Transifex awesome :)
- I get to control exactly when POT file changes are pushed and
when PO
file updates are pulled.
Under what circumstances do you envisage maintainers might want to ship
obsolete or less complete translations? Conversely, if your POT files
aren't ready for translation, why are you pushing them into the repo?
And of course, you could do that with the previous Transifex as well.
- Developers can use whatever VCS they want without needing to
worry
about Transifex support. Back in the early days, Toshio had to spend
time writing a Bazaar plugin in order to get Transifex support for
his projects. Other developers use Monotone, Darcs, or maybe they
don't use a VCS at all. The new model allows all of these people to
use Transifex without issue.
All true; of course, once a plugin exists, everybody benefits. It's also
a pity that it was either/or and that Transifex didn't have a fallback
mechanism for the less widely used VCSes or projects without a VCS. What
proportion of projects are we really talking about anyway?
Translator:
- Common strings between projects can be shared.
Does this happen? How much does it happen? In any case, I'm sceptical of
the utility of matching strings taken from completely different
contexts, but perhaps translators feel this isn't an issue?
- Better failure handling. If the project's repo is down or
unreachable for any reason, translations don't get denied - instead,
they get saved, and the developer will still be able to pull and use
them later (this kind of falls under sysadmin and developer too).
I concur that this is a very real benefit. It's a shame that Transifex
can't do both -- in other words, if it can't reach the project repo,
that it stores the translation and alerts the maintainer and translator
that there's been a problem but that the translation is safely stored
for now.
> I am really very sorry that Red Hat has not stepped into the gap
earlier
> to offer support for this part of the infrastructure and that the
> situation had to reach this crisis point. Nevertheless, the offer is out
> there now. If the L10N team accepts our help, we will of course need to
> put a plan in place to ensure that we provide some ongoing support (as
> we do with Bugzilla) -- at least until if and when somebody else in the
> community develops an interest in maintaining the instance.
I appreciate your work to find resources to maintain a Transifex
instance, although the timing is pretty late, yes. I'm still not clear
on exactly what freedoms we're losing out on, for the reasons I gave
above.
Also note that even if we have some people dedicated to running
Transifex for Fedora, the cost of maintaining it doesn't go away
entirely. We still have to dedicate server resources, get woken up by
alerts when it goes down, get the new sysadmins onto the team and
trained on how we do things, and so on.
Acknowledged.
> Thanks again for the vote of confidence; it means a lot to me.
I'm not
> deluded enough to imagine that this will be an easy task! :)
Sorry to say this, but it's not quite a vote of confidence yet :-) I'm
still trying to get more of a understanding on the reasons that some
people don't want to move to
transifex.net.
The most fundamental reason is giving up control of a large and
important piece of Fedora infrastructure to an outside entity. That's
seriously unpalatable to a lot of people -- any understanding of why
people don't want to move to
transifex.net pretty much relies on
acknowledging that, even if you don't feel the same way personally.
We obviously agree that having
transifex.net host the instance results
in less work for infra, but beyond that I'm not convinced that the move
to
transifex.net is better for developers or translators for any reason
other than the reliability of maintenance (which is more-or-less the
same point as it being less work for infra).
Thanks for the detailed reply and sorry that my response has taken so
long -- I wanted to get it right. I'm taking particular notice of the
advantages that you perceive in the move to
transifex.net -- they
provide very useful insight even where I do not necessarily agree.
Cheers
Rudi