L10N migration to transifex.net
noriko at fedoraproject.org
Fri Feb 25 04:21:39 UTC 2011
Stephen John Smoogen さんは書きました:
> 2011/2/24 Karsten Wade <kwade at redhat.com>:
>> Caveat here: I wasn't in any meetings, had no foreknowledge of
>> anything, and am not involved in any of these activities. I'm an
>> observer who just read that IRC log and some mailing list threads over
>> the last few days. I'm going to attempt to keep my reply within the
>> confines of these recent activities and my general knowledge of how to
>> do things the open source way.
>> The IRC log in question:
>> On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
>>> I'm a little confused by the nature of the meetings you're talking about
>>> though. I was only at the docs meeting, and that didn't seem to include
>>> any weighing up of options. For that matter, the L10n meeting didn't
>>> either, based on the logs -- it reads to me more like a fait accompli.
>> I think you are right, and there was clearly confusion about the
>> meaning of the vote. My reading is that everyone understood what they
>> were voting for at the end. It was clear people felt it was rushed,
>> uninformed, and risky to proceed. However, the plans do seem to have
>> seen adjustment in response to L10n concerns.
>> I read the results of the L10n meeting as:
>> Infra: "We really hate to do this, but we have no choice and no time
>> to do anything other than move all L10n services to Tx.net
>> immediately. Sorry about the late notice."
First of all, I like to express our sincere thanks from our bottom of
hearts to you and all your team members for every effort and time spent
for L10n. Now please allow me to ask further help to understand a little
more the situation where we are standing. It will help to establish an
exit plan in the future.
> Hmm then I was not communicating very clearly:
> The issue was that transifex has been an ongoing problem for the
> following reasons:
> 1) It is a moving target. Development upstream is fast moving and
> adding new features that translators want.
It seems natural that every software is moving better, adding new
features. However if a feature newly to be added may interfere existing
function, as a user translator, I wish not to have a new feature added.
> 2) We are really really behind on upgrades. There have been multiple
> groups who have stepped up, started to do it and then had real life
> hit them with some sort of curve ball. So what started out as 0.7 ->
> 0.8 became 0.7 -> 0.9 and now would have to be 0.7 -> 1.1. We had
> multiple people who for the last 3-4 months have said "We would be
> happy to upgrade, but we aren't really able to do more than that."
I see. So not enough resource can be assigned to such **frequent upgrade
tasks from long term view.
What I am understanding is that the problems we are encountering are
caused by older version, and that the solution is to only upgrade. Is
this correct understanding?
Please let me make the point clear that L10n just wants stable working
version, not necessarily keep upgraded.
What if we upgrade less often?
> 3) We could have kept the old transifex going but this seemed to cause
> more problems than it solved. There have been many items where people
> were 'hamstrung' with the current software and wanted us to move to
> something new.
The old transifex above means v0.7 or v0.9.1?
Who is 'people' and what 'items' make these people hamstrung?
At least, there were actually v0.9.1 up on the staging server and
running, which beckerde and lots of people put their time, blood, sweat
and tears . Many of language teams leaders who put themselves in CC
had been watching this ticket and hoping/expecting the v0.9.1 system to
be implemented onto production. What it the cause to make this ticket
Thanks in advance for your help.
> 4) In looking at Infrastructures current status I realized that we
> were spending a lot of time on triage and not moving forward with
> projects (and in some cases were moving backwards). We looked at what
> our core missions were and what we could have other people do better.
> And it meant pruning back stuff we were not doing well so we could
> focus on getting things done elsewhere.
> Now where we did not hand off things well.
> 1) We asked people in L10N and docs about it but did not make sure
> that was communicated clearly with their groups. That meant we ended
> up with thinking we had agreement but didn't.
> 2) Web software is hard to keep up with unless people stick to it.
> Volunteer infrastructure scales well for certain items but has had
> problems with long term projects. [This is no different than dealing
> with drupal, plone, most Ruby on Rails etc. If your software is
> updating every 3-6 months it is hard to deploy in a production
> environment unless you have dedicated people to keep up with it.]
> 3) As I said in my blog post on this and some other items:
> Now usually after a post like this occurs, we get a bunch of
> volunteers who will say "We can take this over." I am asking people
> not to do this, because frankly volunteering under pressure usually
> means leaving when the pressure is gone. We have gone this route
> several times before, and its not something I think is sustainable.
> We will look for volunteers who can replant the services, document
> them, build out a staging and production service and train OTHER
> volunteers on them so that any replacement service has a chance of
More information about the trans