On 07/24/2012 06:39 AM, Petr Viktorin wrote:
On 07/24/2012 01:12 AM, John Dennis wrote:
On 07/23/2012 06:27 AM, Petr Viktorin wrote:
As a translator (for another project), I don't like Transifex and prefer
to send good old Git pull requests. I understand a "traditional"
workflow is hard to coordinate with others that use Transifex, but still
I'd hate it if we became dependent on Tx.

For better or worse we are dependent on TX (Transifex). Fedora has
adopted TX as it's translation tool, RHEL's translation tools integrate
with TX (as well as other translation portals). And SSSD and IPA have
made a a commitment to TX based on the direction of Fedora and RHEL.

Given that we've adopted TX I don't see the value in maintaining tools
that support both TX and non-TX workflows. I'd rather see us delete the
non-TX elements. If we have just one workflow it's easier to understand
and maintain the code. If we ever decide we need to go back to a non-TX
workflow we can always retrieve the deleted code from git.


This means you have to be a member of a Fedora translation team to
translate.

Actually we're not using the Fedora TX instance, rather the transifex.net instance so I don't think we're limited to translators who are members of a Fedora translation team.

> It makes it harder for people to fork the project. A workflow
with a mandatory central repository makes it impossible to experiment
locally.
I'm all for having a standard way to receive contributions, but limiting
how people can create those contributions isn't good.

I'm all for deleting unused code, but here I think it would be a bad move.


Actually I don't have strong feelings about this one way or the other. My primary concern with two different workflows was that we have to test and maintain both and one of them is currently unused. My other concern is the added complexity, most developers and release engineers don't understand this stuff so keeping is simple to accommodate those less familiar with the process seemed like a win.

But you have a valid point about being flexible, so it's fine with me to keep the old code. We probably need better documentation.

John



--
John Dennis <jden...@redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to