On 02/17/2011 12:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
Cheers Rudi
On 2011-02-21 01:33:01 PM, Ruediger Landmann wrote:
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
First, let me say - I'm happy as long as the work gets done to make a Transifex instance usable and maintained for translators.
But one question - can you quantify exactly what we lose with switching to transifex.net? We discussed this in infrastructure, and the conclusion was that we only lose FAS auth (and we already spoke to spot about any CLA issues, and he said that it shouldn't be an issue). In return, we get an actually maintained Transifex instance that won't be (often) unusable and slow for translators.
What independence do we have with running our own instance? We don't have the people to maintain/upgrade it, and while we have the freedom to make code changes to our instance, we certainly don't have the manpower to actually make that happen. On the other hand, Dimitris and other Transifex developers have already been willing to put time into helping us with our instance, taking bug reports and patches from us, and making sure that we have good service on transifex.net.
The infrastructure team is already really happy not to have to put manpower into running bugzilla.redhat.com, and the way I see it, having a similar arrangement with transifex.net would be great for everybody.
Thanks, Ricky
Ruediger Landmann さんは書きました:
On 02/17/2011 12:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
+1. Thank you very much for your proposal, I like to see this up and running. This is what we originally wanted. Fully functional transifex on fp.o allows all translators to continue working on same instance using same system without hassle for F15 software translation period which already started. Addition to this, translators can also be authenticated via FAS (cvsl10n group) as usual. It won't disturb other teams such as developers and web team by imposing the task for move as well.
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
Indeed. We, Fedora Localization Project, will grow day by day but unlikely shrink. If doubt, check Fedora weekly news, new translators joined are listed every two to three weeks. Hosting the system on Fedora home is fair to all.
noriko
Cheers Rudi
On 2011-02-21 03:01:10 PM, noriko wrote:
It won't disturb other teams such as developers and web team by imposing the task for move as well.
Actually, that's not the case - if we upgrade to 1.1, all projects that use Transifex for translations will still have to change their workflow for the new version in the same way that they would have to with moving to transifex.net.
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.
I still don't understand why some people seem so against switching to transifex.net though :-/
Thanks, Ricky
On 02/21/2011 02:40 PM, Ricky Zhou wrote:
First, let me say - I'm happy as long as the work gets done to make a Transifex instance usable and maintained for translators.
Thanks Ricky :)
But one question - can you quantify exactly what we lose with switching to transifex.net?
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.
To me, this situation is analogous, and it's important to me that Fedora retains this freedom. Freedom means having the power to do something, not that you necessarily do that thing.
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.
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.
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! :)
Cheers Rudi
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 will investigate whether Red Hat can provide resources to either reincorporate this feature into the version of Transifex that we deploy, or at the very least, automate synching the Transifex database with the fedorahosted repos.
Cheers, Rudi
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).
To me, this situation is analogous, and it's important to me that Fedora retains this freedom. Freedom means having the power to do something, not that you necessarily do that thing.
I don't think the situation is analogous to free vs. proprietary software. Again, Transifex is open source, and if we ever have the need, we can download/modify the source and go back to running our own version (although I don't really see this need arising, since they seem to have been great about helping us satisfy our needs in terms of features so far). Until such a need arises, we can save a ton of maintenance/sysadmin time by not running our own instance.
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 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.
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. - I get to control exactly when POT file changes are pushed and when PO file updates are pulled. - 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.
Translator: - Common strings between projects can be shared. - 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 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.
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.
Thanks, Ricky
написане Mon, 21 Feb 2011 08:10:55 +0200, Ricky Zhou ricky@fedoraproject.org:
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.
From the point of view of a translator (that is my private point of view):
1) transifex.net is as trashy as Launchpad was not in its wildest days. Anyone can register the project with no obligation to its translators at all. Noone looks at the licensing of these translations. Launchpad at least does not allow projects of "just for me" translations. If this practice on transifex.net will be continued, the server of the project become very overloaded by the trash.
2) Many developers seems do not care at all (or do not know anything) about updating the templates of their projects (packagekit, shared-mime-info, quassel, freeipa(?), et al.). I believe that current scheme of 1.0+ does not work and should be rearranged. It is very unusual for developers and translators.
3) Interface of 1.0+ is very crowded and overloaded. There is no way to switch back to classic interface. In Tx 0.9 it is suffice to push one button to do anything. In 1.0 you have to push two or more buttons to do the same thing. Search function does not work for localized messages. Translation memory does not work (anyway Lokalize do it in magnitudes better, but the fact is not very promising).
4) polib (the engine of new transifex) suffers from severe bugs due to implementation of some Python string functions. These bugs can lead to impossibility of localized Fedora installation.
5) Current t.fp.o installation "just works" regardless to the frustration that we have in the past.
There is no time enough to test everything thoroughly before Lovelock will be released. The bugs in Fedora 15 can severely damage GNOME 3.0 reputation.
That is why I think that transition (even transition to 1.0 in t.fp.o) should be postponed to past Lovelock period.
Best regards, Yuri Ukrainian translator
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,
On 02/21/2011 06:25 AM, Ruediger Landmann wrote:
On 02/21/2011 02:40 PM, Ricky Zhou wrote:
First, let me say - I'm happy as long as the work gets done to make a Transifex instance usable and maintained for translators.
Thanks Ricky :)
But one question - can you quantify exactly what we lose with switching to transifex.net?
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.
To me, this situation is analogous, and it's important to me that Fedora retains this freedom. Freedom means having the power to do something, not that you necessarily do that thing.
+1
I completely agree with Rudi. An own infrastructure is always better because it *can* be adjusted for the needs of the project if needed.
Thanks,
Luc
On Mon, Feb 21, 2011 at 4:33 AM, Ruediger Landmann r.landmann@redhat.com wrote: [snip]
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
Cheers Rudi
Thanks for the proposal. +1 to run our own instance.
As translator, we just need a running instance. As our current instance is running with issues for at least 1 year, the question is why no discussion between l10n and infra was done before. And I've not seen any request on the trans mailing list to joining the infra...
Translators just need to translate efficiently. This could not be done with the current instance for every projects. The move to txn appears to not be complete (I've at least seen 3 bug reports) but should not take too long. Having more people joining/helping the infra for a week is really great. The most important is to see with the infra how could we handle the transifex instance in a long term, but you, Ruediger, told us that this should not be a problem, thanks! (Guarantee should be discussed with the infra team). Therefor, as a l10n member, the most important is to have a working workflow. Having fas auth is great, but not mandatory.
As a Fedora Project contributor, Fedora running its own instance is better as we have a strong community who do great job. Having the power to decide is better that choosing an alternate solution because we don't have the power.
In an other hand, running our own instance would help Indifex in two ways. First, we won't use their bandwith as told before, and secondly, we would be an example of their product reuse. Having our Open Source software reused is one of the Freedom goal.
Anyway, thanks for the proposal, and thanks to people working on the txn move. We have taken a decision last week... If we want to change our mind, we should do it quickly but this really concern the infra team.
Regards,
The Transifex.net instance appears to be not able to download source file (.pot), that cause translators work more to create a new po or to simply update their local po file; while the fedora one still provides the function to download the pot file.
In my opinion, although the new features provided by v1.1.0 instance are quite awesome (at least for me), there are still some flaws should be fixed as soon as possible to be the new translation platform for Fedora translators.
Le 21/02/2011 08:12, Yuri Chornoivan a écrit :
написане Mon, 21 Feb 2011 08:10:55 +0200, Ricky Zhou ricky@fedoraproject.org:
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.
From the point of view of a translator (that is my private point of view):
- transifex.net is as trashy as Launchpad was not in its wildest days.
Anyone can register the project with no obligation to its translators at all. Noone looks at the licensing of these translations. Launchpad at least does not allow projects of "just for me" translations. If this practice on transifex.net will be continued, the server of the project become very overloaded by the trash.
- Many developers seems do not care at all (or do not know anything)
about updating the templates of their projects (packagekit, shared-mime-info, quassel, freeipa(?), et al.). I believe that current scheme of 1.0+ does not work and should be rearranged. It is very unusual for developers and translators.
- Interface of 1.0+ is very crowded and overloaded. There is no way to
switch back to classic interface. In Tx 0.9 it is suffice to push one button to do anything. In 1.0 you have to push two or more buttons to do the same thing. Search function does not work for localized messages. Translation memory does not work (anyway Lokalize do it in magnitudes better, but the fact is not very promising).
- polib (the engine of new transifex) suffers from severe bugs due to
implementation of some Python string functions. These bugs can lead to impossibility of localized Fedora installation.
- Current t.fp.o installation "just works" regardless to the frustration
that we have in the past.
There is no time enough to test everything thoroughly before Lovelock will be released. The bugs in Fedora 15 can severely damage GNOME 3.0 reputation.
That is why I think that transition (even transition to 1.0 in t.fp.o) should be postponed to past Lovelock period.
Best regards, Yuri Ukrainian translator
I'm very surprised about your reaction.
The l10n project ahs been requesting for help for about a year now. Now that some solution has been found and decision taken, you seems to wake up to disagree.
No perfect solution exists, what do you suggest according to YOUR time and availability to make it work?
Regards,
Thomas
Le 21/02/2011 08:12, Yuri Chornoivan a ?crit :
написане Mon, 21 Feb 2011 08:10:55 +0200, Ricky Zhou ricky@fedoraproject.org:
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.
From the point of view of a translator (that is my private point of view):
- transifex.net is as trashy as Launchpad was not in its wildest days.
Anyone can register the project with no obligation to its translators at all. Noone looks at the licensing of these translations. Launchpad at least does not allow projects of "just for me" translations. If this practice on transifex.net will be continued, the server of the project become very overloaded by the trash.
- Many developers seems do not care at all (or do not know anything)
about updating the templates of their projects (packagekit, shared-mime-info, quassel, freeipa(?), et al.). I believe that current scheme of 1.0+ does not work and should be rearranged. It is very unusual for developers and translators.
- Interface of 1.0+ is very crowded and overloaded. There is no way to
switch back to classic interface. In Tx 0.9 it is suffice to push one button to do anything. In 1.0 you have to push two or more buttons to do the same thing. Search function does not work for localized messages. Translation memory does not work (anyway Lokalize do it in magnitudes better, but the fact is not very promising).
- polib (the engine of new transifex) suffers from severe bugs due to
implementation of some Python string functions. These bugs can lead to impossibility of localized Fedora installation.
- Current t.fp.o installation "just works" regardless to the frustration
that we have in the past.
There is no time enough to test everything thoroughly before Lovelock will be released. The bugs in Fedora 15 can severely damage GNOME 3.0 reputation.
That is why I think that transition (even transition to 1.0 in t.fp.o) should be postponed to past Lovelock period.
Best regards, Yuri Ukrainian translator
I'm very surprised about your reaction.
The l10n project ahs been requesting for help for about a year now. Now that some solution has been found and decision taken, you seems to wake up to disagree.
No perfect solution exists, what do you suggest according to YOUR time and availability to make it work?
Regards,
Thomas
Hi!
Please do not get me wrong, but the only thing I wanted to say: "It was the wrong time to change the horses". If it was two (or even one) month ago, I would strongly say "Yes!!!" (just for myself) and did my best to iron out the glitches.
I do not wake up just now. I had a lecture during the session on this question, so could not attend it.
All these things were decided in three days (maybe I missed something?). Some people might not even recognized this (see commits to t.fp.o). There were many discussions last year in this list, but the change in a first day of freeze was just like lightning strike or Micronokia deal (fast and right).
Now I can only say that we have no time before release. I invested MY time into Fedora translation and if now it is just a matter of leaders decision to make a move that will ruin parts of my work... Well, I will do my best to solve the issues, but cannot guarantee that the small team like ours can invest enough of OURS time to make things run as they should in three weeks that left (we did not even see the new documentation).
That's all.
On Mon, Feb 21, 2011 at 1:04 PM, Tseng, Cheng-Chia pswo10680@gmail.com wrote:
The Transifex.net instance appears to be not able to download source file (.pot).
The English file itself acts as a POT file (source language).
As mentioned previously, all the technical observations reported are characteristics of v1.0, not Transifex.net itself.
-d
2011/2/21 Yuri Chornoivan yurchor@ukr.net: [snip]
Please do not get me wrong, but the only thing I wanted to say: "It was the wrong time to change the horses". If it was two (or even one) month ago, I would strongly say "Yes!!!" (just for myself) and did my best to iron out the glitches.
I do not wake up just now. I had a lecture during the session on this question, so could not attend it.
All these things were decided in three days (maybe I missed something?). Some people might not even recognized this (see commits to t.fp.o). There were many discussions last year in this list, but the change in a first day of freeze was just like lightning strike or Micronokia deal (fast and right).
Now I can only say that we have no time before release. I invested MY time into Fedora translation and if now it is just a matter of leaders decision to make a move that will ruin parts of my work... Well, I will do my best to solve the issues, but cannot guarantee that the small team like ours can invest enough of OURS time to make things run as they should in three weeks that left (we did not even see the new documentation).
That's all.
Why we took the decision so quickly? Because many translators think (and start thinking at least for one year) that our instance is not working *efficiently*. Yuri, have you ever spent a *full day* trying to submit 10 files, when it should take at most 10 minutes? It is really slow and working differently for each project/files. Some projects work really well, other don't. Depends of time/people spending time to correct it in the infra side.
Therefor, we needed to have a new platform. Taking the decision was fast because lot of people stepped up and said "yes, we need a solution and I could do that or that!". It was a late decision, but we just can't postpone it every release.
Even if we are in freeze time, we can translate offline. We just need to know where and when we should commit... And to be able to commit.
2011/2/21 Ruediger Landmann r.landmann@redhat.com:
On 02/17/2011 12:43 AM, Zach Oglesby wrote:
Over the last few days it has been decided that we are going to move all of Fedora's translation efforts away from a self hosted solution and on to transifex.net.
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
Just for the record, the original idea was the following:
1. update Tx package from 0.7.4 to 0.9.x in order to update t.fp.o instance. 2. update t.fp.o instance to 0.9.x 3. once we have a Tx 0.9.x version successfully running on t.fp.o, package the new 1.x series. 4. update t.fp.o instance to 1.x series.
Tx 0.9.1 was packaged successfully and tested to work fine at [1], a staging instance which is still up and running.
The workflow has got stuck in step 2.
If you need it, I may release ownership for EPEL packages too.
kind regards
Domingo Becker
2011/2/21 Domingo Becker domingobecker@gmail.com:
Tx 0.9.1 was packaged successfully and tested to work fine at [1], a staging instance which is still up and running.
Sorry, I forgotten the link.
On Sun, Feb 20, 2011 at 10:33 PM, Ruediger Landmann r.landmann@redhat.com wrote:
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Sorry for the slow response -- I wasn't keeping up with email for much of the weekend, and didn't see this thread until this morning. I understand your point here regarding our independence, but I don't see any vendor lock-in here. The software is the same open-source software we'd be running on our intrastructure -- it's just that Indifex has offered to take care of the hosting/upgrades/maintenance of it for us. Because it's open source and we have the ability to host it ourselves at any time, it really comes down to a matter of trust. Personally, I can say that I unequivocally trust Dimitris, because I've seen the work he's done in Fedora both as a contributor and a former member of the Fedora Board.
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
That's fine, but you need to coordinate that with both the Infrastructure team and the rest of the L10N team. Having spoken to the Infrastructure team about this several times over the past few days, I know their first concern is going to be the dedication of these resources. In other words, they're not just looking for someone who can upgrade us to 1.0 (or 1.1-dev) now, but *guaranteed resources* to keep it upgraded and maintained and bugs fixed over the *long haul*.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
With all respect Rudi, it's not just about the Localization team... We had meetings last week between the L10N team, the Infrastructure team, the Docs team, FESCo, the Fedora Program Manager, and myself. We weighed all the pros and cons of the move, and we decided as a group to move forward with the migration to transifex.net. We migrated the translations to transifex.net last Friday. We've got a deadline of having the transifex client packaged up and ready to go for package maintainers by this coming Friday. Any delay (or switch to another platform) adds additional burden to our L10N team, especially when we're already past the string freeze and into their translation time.
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
I don't think Dimitris would have made us the offer to host our translations if he would have thought that it would be unfair to Indifex. I agree that Indifex is a commercial venture and that the work they're offering does cost them money, but if Dimitris and company are OK with that, how can I argue against it? On the maintenance/upgrades side of things, that's work they already have to do for their other clients. On the bandwidth side of things, I'm sure they'll yell if their bandwidth costs get too high, and then we'll make a determination on whether to compensate them for bandwidth, move to being self-hosted again, or find some other solution.
May I also suggest that we move this discussion to the logistics mailing list, since the discussion needs to include more people than just the Docs or the Translation teams?
-- Jared Smith Fedora Project LEader
On Sun, Feb 20, 2011 at 10:33 PM, Ruediger Landmann r.landmann@redhat.com wrote:
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
Does this seem acceptable?
Just as a quick follow-up, I discussed this with the Fedora Board in our board meeting today, and we agreed that the best time to revisit the decision to migrate to transifex.net is after the F15 release. We don't want to run the risk of further shortening the time remaining for translations.
(Futher discussion on the logistics list, I promise!)
-- Jared Smith Fedora Project Leader
On Mon, Feb 21, 2011 at 3:26 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
Just as a quick follow-up, I discussed this with the Fedora Board in our board meeting today, and we agreed that the best time to revisit the decision to migrate to transifex.net is after the F15 release. We don't want to run the risk of further shortening the time remaining for translations.
Ugh, I typed this email too quickly and obviously messed up. That should have read "migrate *from* transifex.net", not "migrate to transifex.net". In short, we're still moving to transifex.net now, and will re-evaluate things after the F15 release. I apologize for any confusion I caused.
-- Jared Smith Fedora Project Leader
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
[note: CCed to logistics list as suggested; see below]
On 02/22/2011 03:02 AM, Jared K. Smith wrote:
On Sun, Feb 20, 2011 at 10:33 PM, Ruediger Landmann r.landmann@redhat.com wrote:
This decision has greatly saddened and disappointed me. With all respect to Dmitris and his team, to me, it seems like Fedora is giving up a key part of our infrastructure and our independence.
Sorry for the slow response -- I wasn't keeping up with email for much of the weekend, and didn't see this thread until this morning. I understand your point here regarding our independence, but I don't see any vendor lock-in here. The software is the same open-source software we'd be running on our intrastructure -- it's just that Indifex has offered to take care of the hosting/upgrades/maintenance of it for us. Because it's open source and we have the ability to host it ourselves at any time, it really comes down to a matter of trust. Personally, I can say that I unequivocally trust Dimitris, because I've seen the work he's done in Fedora both as a contributor and a former member of the Fedora Board.
Thanks Jared; and sorry for my slow reply too. I don't think anything is gained by further haste at this point, and I've been taking some time to think through my responses.
First, can we please clear the air of any notion of vendor lock-in? That has never been a concern of mine, and I hope that I have not said anything to suggest that it was. I think we can agree that you can be dependent on someone or something even without being locked in. You otherwise understand what I'm saying about dependence, so really, the point of contention is "only" whether in this case, the dependence is good, bad, or indifferent! :)
Second, I'd like to put the question of trust aside as well. Dimitris has certainly established his credentials and bona fides within our community. When you suggest that the move to Transifex.net comes down to "a matter of trust" you risk reframing the discussion from "do we think that moving Fedora's translation infrastructure to an external provider is a good idea or not?" to "do we trust Dimitris or not?" It's just not fair to personalize the discussion that way, and I would hate to think that anybody would equate "doesn't support the move to transifex.net" with "doesn't trust Dimitris".
Therefore, I have obtained permission from my manager to put time and resources into packaging Transifex 1.1 for fedoraproject.org. I have also had the time and skills of two Red Hat sysadmins allocated to get Fedora's own instance of Transifex upgraded and migrated ASAP.
That's fine, but you need to coordinate that with both the Infrastructure team and the rest of the L10N team. Having spoken to the Infrastructure team about this several times over the past few days, I know their first concern is going to be the dedication of these resources. In other words, they're not just looking for someone who can upgrade us to 1.0 (or 1.1-dev) now, but *guaranteed resources* to keep it upgraded and maintained and bugs fixed over the *long haul*.
Of course! :) I am working on getting something formalized in this direction. Are the terms of the Fedora Project's service-level agreement with Indifex a matter of public record? (and will performance reports be publicly available to the community?)
I believe that if the Fedora Localization Project is open to the idea, we could have an up-to-date and fully functional local instance of Transifex 1.1 available within a week.
With all respect Rudi, it's not just about the Localization team... We had meetings last week between the L10N team, the Infrastructure team, the Docs team, FESCo, the Fedora Program Manager, and myself. We weighed all the pros and cons of the move, and we decided as a group to move forward with the migration to transifex.net. We migrated the translations to transifex.net last Friday. We've got a deadline of having the transifex client packaged up and ready to go for package maintainers by this coming Friday. Any delay (or switch to another platform) adds additional burden to our L10N team, especially when we're already past the string freeze and into their translation time.
Understood, and I agree that added delay and uncertainty at this point would pose a significant and unfair burden to translators. I'm sorry that other options were not made available earlier. Thank you very much for raising the issue with the Board (as you related in your follow-up email, not quoted here) and I concur that it makes more sense to revisit this after F15 is out the door. Your firm hand on the rudder is appreciated :)
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.
On the subject of the L10n meeting: I'm in a difficult position. I'm proud to number some of the people who participated in that meeting amongst my friends, so I *really* don't want to single out specific people or comments in the log. Also, IRC doesn't capture the nuances of human communication very well and I can't discount the possibility that I'm badly misreading the tone of the meeting. So, all I can do is invite anyone who's interested to go and read the log at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
One specific thing in there that does confuse me though is the vote that occurs about 96 minutes into the meeting; I don't really understand what was going on there or how it fits together with the idea that the decision about where to host Fedora's translation infrastructure wasn't just up to the Fedora Localization Project. I'd appreciate clarification from anyone who was at the meeting.
I also want to take this opportunity to thank Dmitris for his extremely generous offer to host this massive project on behalf of Fedora. However, apart from the reasons I gave earlier, I also can't help but feel that this direction would be grossly unfair on Dmitris and his business. Indifex is, after all, a commercial venture, and server resources and bandwidth aren't free of charge -- especially on the scale contemplated for Fedora. Just before I came to work for Red Hat, I owned a small IT business myself, and know that every penny counts! :)
I don't think Dimitris would have made us the offer to host our translations if he would have thought that it would be unfair to Indifex. I agree that Indifex is a commercial venture and that the work they're offering does cost them money, but if Dimitris and company are OK with that, how can I argue against it? On the maintenance/upgrades side of things, that's work they already have to do for their other clients. On the bandwidth side of things, I'm sure they'll yell if their bandwidth costs get too high, and then we'll make a determination on whether to compensate them for bandwidth, move to being self-hosted again, or find some other solution.
Great :) Like I said, it's a very generous offer by Dmitris and Indifex, and whether or not I personally agree with the move, I applaud the commitment that it shows.
So there's room in the Fedora budget to compensate Indifex if the need arises?
May I also suggest that we move this discussion to the logistics mailing list, since the discussion needs to include more people than just the Docs or the Translation teams?
of course -- CCing them in.
In conclusion, I'm really conflicted here, because on the one hand I don't want to strain friendships or to be obstructionist, but on the other hand I feel compelled to speak up about a decision (and a process) that disturbs me.
Cheers Rudi
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:
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
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."
L10n: "Wow, that is really surprising, I don't know if I support this all the way and want some protection in place. I see it's too late to do anything else for the F15 cycle so I'll support the move with the agreement that we revisit this discussion as many of us would prefer to have L10n services hosted by the Fedora Project if we can."
From what I read in that log, the lateness in the F15 cycle meant a program mangement and project leadership decision had to be made, which was really to support what Infrastructure had already decided made the most sense. Bringing it all-of-a-sudden to L10n with a mysteriously-valuable vote in the wings seemed to add to the confusion.
However, do I see that the whole discussion has raised some items that were not fait accompli, which I cover below.
On the subject of the L10n meeting: I'm in a difficult position. I'm proud to number some of the people who participated in that meeting amongst my friends, so I *really* don't want to single out specific people or comments in the log. Also, IRC doesn't capture the nuances of human communication very well and I can't discount the possibility that I'm badly misreading the tone of the meeting. So, all I can do is invite anyone who's interested to go and read the log at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
One specific thing in there that does confuse me though is the vote that occurs about 96 minutes into the meeting; I don't really understand what was going on there or how it fits together with the idea that the decision about where to host Fedora's translation infrastructure wasn't just up to the Fedora Localization Project. I'd appreciate clarification from anyone who was at the meeting.
Thank you for your email, it is an excellent summary of the situational concerns, has some good resolution, and shines light on the path we can keep moving down.
In conclusion, I'm really conflicted here, because on the one hand I don't want to strain friendships or to be obstructionist, but on the other hand I feel compelled to speak up about a decision (and a process) that disturbs me.
Definitely there was some process breakdown and some lack-of-process.
It seems that it wasn't an active open community discussion between Infrastructure and affected teams about problems with maintaining translate.fp.org and how to fix them. This all could have been discussed over the preceding months, presuming that were possible ... and I am going to presume it wasn't, that we are here based on a series of best-efforts and best-will from people involved. Does that make sense?
Jared and Paul said in the meeting log multiple times that we needed to avoid people being surprised by the situation, but unfortunately that wasn't very likely. The timing involved made it a certainty that some people were going to be squeezed, surprised, and upset.
I perceive the following items as fait accompli before that meeting happened:
* Fedora Infrastructure decided they could no longer provide translation services.
* To meet their service obligations, FI put in place a plan to move translation services to Transifex.net.
* Fedora Project leadership were essentially in agreemen with that plan.
I didn't see the following items as fait accompli before that meeting:
* Future of hosting our own translation tool of any kind on fedoraproject.org. Clearly we can revisit this decision, clearly people wanted to.
* Ability for resourceful people to step forward and make it possible to either not move for F15 or move back for F16. For example, you seem to have responded to this by seeking new, on-going resource commitments.
* Commitment of L10n leadership toward any particular plan. People came in to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
1. Exposes problems (needs for change) early and often. 2. Encourages discussion and work so decisions (why, how) are visible to all affected. 3. Makes sure affected teams are not surprised by developments.
I have seen the Fedora Program Manager and various teams work this process manually over the years, but I'm not sure how many teams have a change management process in place so they can reduce surprise with other Fedora teams?
- Karsten
On Thu, Feb 24, 2011 at 11:08 PM, Karsten Wade kwade@redhat.com wrote:
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:
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
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."
L10n: "Wow, that is really surprising, I don't know if I support this all the way and want some protection in place. I see it's too late to do anything else for the F15 cycle so I'll support the move with the agreement that we revisit this discussion as many of us would prefer to have L10n services hosted by the Fedora Project if we can."
From what I read in that log, the lateness in the F15 cycle meant a program mangement and project leadership decision had to be made, which was really to support what Infrastructure had already decided made the most sense. Bringing it all-of-a-sudden to L10n with a mysteriously-valuable vote in the wings seemed to add to the confusion.
However, do I see that the whole discussion has raised some items that were not fait accompli, which I cover below.
On the subject of the L10n meeting: I'm in a difficult position. I'm proud to number some of the people who participated in that meeting amongst my friends, so I *really* don't want to single out specific people or comments in the log. Also, IRC doesn't capture the nuances of human communication very well and I can't discount the possibility that I'm badly misreading the tone of the meeting. So, all I can do is invite anyone who's interested to go and read the log at http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.20...
One specific thing in there that does confuse me though is the vote that occurs about 96 minutes into the meeting; I don't really understand what was going on there or how it fits together with the idea that the decision about where to host Fedora's translation infrastructure wasn't just up to the Fedora Localization Project. I'd appreciate clarification from anyone who was at the meeting.
Thank you for your email, it is an excellent summary of the situational concerns, has some good resolution, and shines light on the path we can keep moving down.
In conclusion, I'm really conflicted here, because on the one hand I don't want to strain friendships or to be obstructionist, but on the other hand I feel compelled to speak up about a decision (and a process) that disturbs me.
Definitely there was some process breakdown and some lack-of-process.
It seems that it wasn't an active open community discussion between Infrastructure and affected teams about problems with maintaining translate.fp.org and how to fix them. This all could have been discussed over the preceding months, presuming that were possible ... and I am going to presume it wasn't, that we are here based on a series of best-efforts and best-will from people involved. Does that make sense?
Jared and Paul said in the meeting log multiple times that we needed to avoid people being surprised by the situation, but unfortunately that wasn't very likely. The timing involved made it a certainty that some people were going to be squeezed, surprised, and upset.
I perceive the following items as fait accompli before that meeting happened:
- Fedora Infrastructure decided they could no longer provide
translation services.
- To meet their service obligations, FI put in place a plan to move
translation services to Transifex.net.
- Fedora Project leadership were essentially in agreemen with that
plan.
I didn't see the following items as fait accompli before that meeting:
- Future of hosting our own translation tool of any kind on
fedoraproject.org. Clearly we can revisit this decision, clearly people wanted to.
- Ability for resourceful people to step forward and make it possible
to either not move for F15 or move back for F16. For example, you seem to have responded to this by seeking new, on-going resource commitments.
- Commitment of L10n leadership toward any particular plan. People
came in to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
- Exposes problems (needs for change) early and often.
- Encourages discussion and work so decisions (why, how) are visible
to all affected. 3. Makes sure affected teams are not surprised by developments.
Yes, we (the infra and trans) should have discussed about our transifex instance more seriously before deciding that it is *really* to late to take time
I have seen the Fedora Program Manager and various teams work this process manually over the years, but I'm not sure how many teams have a change management process in place so they can reduce surprise with other Fedora teams?
- Karsten
--
As seen now that we have started using Transifex.net, is that using the same service as other communities helps collaborate. It is easier to see and join other projects (in both ways) when you can see their file and how their are managed.
On 02/25/2011 08:08 AM, Karsten Wade wrote:
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."
L10n: "Wow, that is really surprising, I don't know if I support this all the way and want some protection in place. I see it's too late to do anything else for the F15 cycle so I'll support the move with the agreement that we revisit this discussion as many of us would prefer to have L10n services hosted by the Fedora Project if we can."
From what I read in that log, the lateness in the F15 cycle meant a program mangement and project leadership decision had to be made, which was really to support what Infrastructure had already decided made the most sense. Bringing it all-of-a-sudden to L10n with a mysteriously-valuable vote in the wings seemed to add to the confusion.
+1 Excellent summary!
So I'm still not following where options were weighed up in open consultation with the community. I agree with your reading of the logs that suggests:
* a firm decision taken by some members of the infra team (who? when? what other options were considered?)
* a firm decision taken by project leadership to support the previous decision (who? when? what other options were considered?)
long before this meeting.
I guess I therefore perceive a serious disjoin between:
* the scenario described above
* the depiction of the move as having been developed in broad consultation or being in any way democratic
If the move was acutally the result of a purely authoritarian, unilaterial "fiat", why not say so? Sometimes decisions like that are indeed necessary in any community, which is why we have leadership -- to make tough and sometimes even unpalatable decisions. But if that was indeed the case (and I'm still open to the idea that I'm badly misreading the situation) -- Why the pretense that it was anything other?
I can easily quantify the disjunction by pointing to specific statements by people in the meeting and in various mailing lists, but I'm not going to single people out this way. I feel bad enough saying *any* of this out loud, because I in no way want to undermine or obstruct our leadership. But nor do I feel like I can just shut up and pretend I'm not seeing what I'm seeing :(
<big snippage -- I really appreciate the analysis and completely endorse your reading of the events, with one exception: >
- Commitment of L10n leadership toward any particular plan. People came in to that meeting with different opinions and agendas, but seemed to come to consensus by the end.
I am not comfortable agreeing with you that consensus existed, when the most obvious gauge of that consensus was a vote:
* that was not advertised as part of the meeting agenda[1] * took place an hour and a half into the meeting * the purpose of which was changing right up to the time the vote was taken * in an environment where dissent had been shot immediately * in an environment where people could tell voters that resistance was futile and those people were not sanctioned * where participants who checked in at the start of the meeting were silent -- under the circumstances, I wouldn't want to claim that their silence was assent * in a multi-cultural environment where standing up and saying "no" in public defiance of authority might be really, really difficult for some people.
In short, nothing about the meeting in general and the vote at 96 minutes in particular makes me feel like it was a safe and supportive environment in which people could express their own opinions freely. I'm a loudmouth, and I'm not sure that *I* would have felt comfortable doing so :(
Community supported infrastructure doesn't have to be of a lesser service level overall, but things tend to be less formal across the board about change impact on community participants.
One lesson to pull from this situation is for *every* service provider (which inclues L10n, Docs, Infrastructure, et al) to have a change management process in place that:
- Exposes problems (needs for change) early and often.
- Encourages discussion and work so decisions (why, how) are visible to all affected.
- Makes sure affected teams are not surprised by developments.
I have seen the Fedora Program Manager and various teams work this process manually over the years, but I'm not sure how many teams have a change management process in place so they can reduce surprise with other Fedora teams?
+1 to all this -- excellent stuff.
Cheers Rudi
[1] http://lists.fedoraproject.org/pipermail/trans/2011-February/008596.html
On 02/24/2011 04:58 PM, Ruediger Landmann wrote:
If the move was acutally the result of a purely authoritarian, unilaterial "fiat", why not say so? Sometimes decisions like that are indeed necessary in any community, which is why we have leadership -- to make tough and sometimes even unpalatable decisions. But if that was indeed the case (and I'm still open to the idea that I'm badly misreading the situation) -- Why the pretense that it was anything other?
I think you are misreading the situation. The Infrastructure team had known for a while that there were problems with the Fedora-local instance of Transifex, and members of the Fedora translator community were complaining about lack of needed functionality.
It was proposed that since the current local transifex instance was not a viable solution for providing translations for Fedora 15, that we consider a move to the hosted tx.net offering (this was also the recommendation from the transifex upstream, who offered to provide this to us at no financial cost).
This solution was presented to the Fedora translation community for consideration (albeit, with not a whole lot of time to decide), and they decided that was a good plan for F15, with the understanding that we can (and probably will) revisit this after Fedora 15 is done.
Can we please put this sort of "pre-made decision" or "decision by fiat" stuff to rest now? There is no attempt to cover anything up, just Fedora Infrastructure trying to identify and deploy a solution that would enable Fedora's translators to complete their work for Fedora 15.
~tom
== Fedora Project
On 02/25/2011 11:16 AM, Tom Callaway wrote:
On 02/24/2011 04:58 PM, Ruediger Landmann wrote:
If the move was acutally the result of a purely authoritarian, unilaterial "fiat", why not say so? Sometimes decisions like that are indeed necessary in any community, which is why we have leadership -- to make tough and sometimes even unpalatable decisions. But if that was indeed the case (and I'm still open to the idea that I'm badly misreading the situation) -- Why the pretense that it was anything other?
I think you are misreading the situation. The Infrastructure team had known for a while that there were problems with the Fedora-local instance of Transifex, and members of the Fedora translator community were complaining about lack of needed functionality.
It was proposed that since the current local transifex instance was not a viable solution for providing translations for Fedora 15, that we consider a move to the hosted tx.net offering (this was also the recommendation from the transifex upstream, who offered to provide this to us at no financial cost).
This solution was presented to the Fedora translation community for consideration (albeit, with not a whole lot of time to decide), and they decided that was a good plan for F15, with the understanding that we can (and probably will) revisit this after Fedora 15 is done.
Hi Tom,
How do we get a commitment that there will be a process to govern this decision?
- Mike
On 02/28/2011 11:58 PM, Mike Hideo wrote:
How do we get a commitment that there will be a process to govern this decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
~tom
== Fedora Project
On 03/02/2011 04:02 AM, Tom Callaway wrote:
On 02/28/2011 11:58 PM, Mike Hideo wrote:
How do we get a commitment that there will be a process to govern this decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
Thank you, Tom.
Should we work the program manager or with yourself directly? I am mindful I am spamming lists.
Cheers, Mike
On 03/02/2011 04:44 PM, Mike Hideo wrote:
On 03/02/2011 04:02 AM, Tom Callaway wrote:
On 02/28/2011 11:58 PM, Mike Hideo wrote:
How do we get a commitment that there will be a process to govern this decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
Thank you, Tom.
Should we work the program manager or with yourself directly? I am mindful I am spamming lists.
Robyn Bergeron is the Program Manager, she should be able to schedule this and ensure that all interested parties are invited.
~tom
== Fedora Project
On Wed, Mar 02, 2011 at 04:49:44PM -0500, Tom Callaway wrote:
On 03/02/2011 04:44 PM, Mike Hideo wrote:
On 03/02/2011 04:02 AM, Tom Callaway wrote:
On 02/28/2011 11:58 PM, Mike Hideo wrote:
How do we get a commitment that there will be a process to govern this decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
Thank you, Tom.
Should we work the program manager or with yourself directly? I am mindful I am spamming lists.
Robyn Bergeron is the Program Manager, she should be able to schedule this and ensure that all interested parties are invited.
Also, Mike, I wouldn't call your input spam by any stretch -- it's on topic, and useful for the community to understand how our work affects downstream consumers, participants, and each other.
On 03/03/2011 11:44 PM, Paul W. Frields wrote:
On Wed, Mar 02, 2011 at 04:49:44PM -0500, Tom Callaway wrote:
On 03/02/2011 04:44 PM, Mike Hideo wrote:
On 03/02/2011 04:02 AM, Tom Callaway wrote:
On 02/28/2011 11:58 PM, Mike Hideo wrote:
How do we get a commitment that there will be a process to govern this decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
Thank you, Tom.
Should we work the program manager or with yourself directly? I am mindful I am spamming lists.
Robyn Bergeron is the Program Manager, she should be able to schedule this and ensure that all interested parties are invited.
Also, Mike, I wouldn't call your input spam by any stretch -- it's on topic, and useful for the community to understand how our work affects downstream consumers, participants, and each other.
Thanks, Paul,
Here is a record of all of the people who have contributed to FLP over the last 11 years.
https://fedoraproject.org/w/uploads/5/54/People.txt
- Mike
On Mon, Mar 7, 2011 at 3:24 AM, Mike Hideo mhideo@redhat.com wrote:
On 03/03/2011 11:44 PM, Paul W. Frields wrote:
On Wed, Mar 02, 2011 at 04:49:44PM -0500, Tom Callaway wrote:
On 03/02/2011 04:44 PM, Mike Hideo wrote:
On 03/02/2011 04:02 AM, Tom Callaway wrote:
On 02/28/2011 11:58 PM, Mike Hideo wrote:
How do we get a commitment that there will be a process to govern this decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
Thank you, Tom.
Should we work the program manager or with yourself directly? I am mindful I am spamming lists.
Robyn Bergeron is the Program Manager, she should be able to schedule this and ensure that all interested parties are invited.
Also, Mike, I wouldn't call your input spam by any stretch -- it's on topic, and useful for the community to understand how our work affects downstream consumers, participants, and each other.
Thanks, Paul,
Here is a record of all of the people who have contributed to FLP over the last 11 years.
https://fedoraproject.org/w/uploads/5/54/People.txt
- Mike
-- trans mailing list trans@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans
nice :) But it's only about softwares. There is nothing about docs nor websites.
2011/3/6 Mike Hideo mhideo@redhat.com:
On 03/03/2011 11:44 PM, Paul W. Frields wrote:
On Wed, Mar 02, 2011 at 04:49:44PM -0500, Tom Callaway wrote:
On 03/02/2011 04:44 PM, Mike Hideo wrote:
On 03/02/2011 04:02 AM, Tom Callaway wrote:
On 02/28/2011 11:58 PM, Mike Hideo wrote:
How do we get a commitment that there will be a process to govern this decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
Thank you, Tom.
Should we work the program manager or with yourself directly? I am mindful I am spamming lists.
Robyn Bergeron is the Program Manager, she should be able to schedule this and ensure that all interested parties are invited.
Also, Mike, I wouldn't call your input spam by any stretch -- it's on topic, and useful for the community to understand how our work affects downstream consumers, participants, and each other.
Thanks, Paul,
Here is a record of all of the people who have contributed to FLP over the last 11 years.
https://fedoraproject.org/w/uploads/5/54/People.txt
- Mike
It looks truly incomplete. I never miss anaconda and system-config-printer translation. I work for those modules almost in every release since 2007 because I use the too much. I'm not there in 2009 [1], 2010 and 2011. I'm not in the list in 2006, I started in August 2006. I also do packagekit translations not so often, but when I see strings untranslated when I use it, And I use it too much. So it might be untranslated in the release but complete before the eol. The translations contribution for rpm and yum are not even listed in 2010, and I contributed for both of them, an example in [2]. For yum, I succeeded uploading translations by sending an email to the package maintainer, remember there was no upload support for yum, and upstream was really unreachable; I guess yum is in other languages because of Fedora and Red Hat not because of upstream.
Daniel Cabrera (logan) is not even listed, and he contributed almost all of the virt-xxx packages. Virtualization support is in Spanish because of Daniel Cabrera and some others who helped there. He helped in many other modules too with so many strings, more than thousands.
Guillermo Gomez (gomix) is missing in the list too. I guess he started since Fedora Core 2, I don't remember now. He knew the translations process when it was the really hard way.
Many friends from Chile, who contributed a lot, are not in the list too.
Some from central and north America are missing there too.
No need to mention docs and websites.
I take this opportunity to express my sincere thanks to all Spanish translators who have ever helped in the Fedora L10N Project and for whom we were not able to acknowledge them somehow. Not even an email that lists them at least.
I'm sure we can improve this in the future.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=481586
[2] https://bugzilla.redhat.com/show_bug.cgi?id=566590
kind regards
Domingo Becker (es)
On 03/08/2011 11:37 AM, Domingo Becker wrote:
2011/3/6 Mike Hideomhideo@redhat.com:
On 03/03/2011 11:44 PM, Paul W. Frields wrote:
On Wed, Mar 02, 2011 at 04:49:44PM -0500, Tom Callaway wrote:
On 03/02/2011 04:44 PM, Mike Hideo wrote:
On 03/02/2011 04:02 AM, Tom Callaway wrote:
On 02/28/2011 11:58 PM, Mike Hideo wrote: > How do we get a commitment that there will be a process to govern this > decision?
What would you like? We can schedule a formal review process with the various community groups to discuss the future of L10N technologies after the F15 release, if that is what you're looking for.
Thank you, Tom.
Should we work the program manager or with yourself directly? I am mindful I am spamming lists.
Robyn Bergeron is the Program Manager, she should be able to schedule this and ensure that all interested parties are invited.
Also, Mike, I wouldn't call your input spam by any stretch -- it's on topic, and useful for the community to understand how our work affects downstream consumers, participants, and each other.
Thanks, Paul,
Here is a record of all of the people who have contributed to FLP over the last 11 years.
https://fedoraproject.org/w/uploads/5/54/People.txt
- Mike
It looks truly incomplete.
Hi Domingo,
Apologies, those credits come from *just* the po file headers.
There are certainly more than 665 unique contributors to the project. I would go so far to say that the files in the Fedora Localization Project represents one of the largest, most unique projects in the history of open source. I want others to add to this history in these files. You and this project bring the desktop in our mother tongues to all the countries' children.
Cheers,
- Mike
I never miss anaconda and system-config-printer translation. I work for those modules almost in every release since 2007 because I use the too much. I'm not there in 2009 [1], 2010 and 2011. I'm not in the list in 2006, I started in August 2006. I also do packagekit translations not so often, but when I see strings untranslated when I use it, And I use it too much. So it might be untranslated in the release but complete before the eol. The translations contribution for rpm and yum are not even listed in 2010, and I contributed for both of them, an example in [2]. For yum, I succeeded uploading translations by sending an email to the package maintainer, remember there was no upload support for yum, and upstream was really unreachable; I guess yum is in other languages because of Fedora and Red Hat not because of upstream.
Daniel Cabrera (logan) is not even listed, and he contributed almost all of the virt-xxx packages. Virtualization support is in Spanish because of Daniel Cabrera and some others who helped there. He helped in many other modules too with so many strings, more than thousands.
Guillermo Gomez (gomix) is missing in the list too. I guess he started since Fedora Core 2, I don't remember now. He knew the translations process when it was the really hard way.
Many friends from Chile, who contributed a lot, are not in the list too.
Some from central and north America are missing there too.
No need to mention docs and websites.
I take this opportunity to express my sincere thanks to all Spanish translators who have ever helped in the Fedora L10N Project and for whom we were not able to acknowledge them somehow. Not even an email that lists them at least.
I'm sure we can improve this in the future.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=481586
[2] https://bugzilla.redhat.com/show_bug.cgi?id=566590
kind regards
Domingo Becker (es)
trans mailing list trans@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/trans
-
Cheng-Chia Tseng -
Dimitris Glezos -
Domingo Becker -
Jared K. Smith -
Karsten Wade -
Kévin Raymond -
Luc de Louw -
Michael Hideo Smith -
Noriko Mizumoto -
Oron Peled -
Paul W. Frields -
Ricky Zhou -
Ruediger Landmann -
Thomas Canniot -
Tom Callaway -
Yuri Chornoivan