[Kde-scm-interest] A concept for "moving to Git" and translations

[Ian Monroe]

2009/5/26 Chusslove Illich <caslav.ilic at gmx.net>:
>> [: Ian Monroe :]
>> I agree that there's no reason translators and programmers should use the
>> same system. However I don't think letting individual projects in KDE pick
>> their own VCS is a good idea. Amarok is probably going to switch before
>> the rest, but this is purely transitional. Keeping all the developers in
>> KDE on the same technological ship is important to the culture, and
>> there's no technology more critical to development then VCS.
>
> This depends on definition of "in KDE" :) If that means "presently in
> central KDE repo", then, well, such definition is obviously going to be made
> void. While (just giving examples, not a policy opinion) core modules may
> all use same VCS, some extragear apps may not.

Well I think all extragear apps are in KDE and should use the same VCS. :)

> For random KDE apps presently
> not in KDE repo (Krusader comes to mind as prominent example), there is
> neither a way (nor the need) to enforce a given VCS. But there is no reason
> for a random KDE app not to be able to benefit from KDE Translation Project
> (KTP), should they want so and agree to terms established by KTP.

Translation is one of the major benefits in having your app join the
KDE project. I don't like the idea of extending it to others.

> But this is all not technically important at all, since there will be two
> VCS (Git and Subversion) for some time, so VCS modularization in Scripty on
> app/module side should anyway be conducted to have reasonably clean code
> (even if Scripty is one big hack all the way down).

I really don't think this transitional period is going to take some
time, though maybe I'm naive. :) We should also keep things pretty
limited, eg only 1-3 apps transition to Git, followed by the mass
transition.

>> I have no clue about what to do with docs. :) Currently they are
>> completely separate from Amarok so we don't have to tackle the issue
>> immediately. (One bonus of Amarok switching first is that we can phase in
>> needed solutions like that one-by-one).
>
> My strong personal opinion is that the original doc should be part of the
> app, i.e. in its repository (with only open question of what one considers
> "an app" in a core module, but that is a special case). I hope that would
> improve the abysimal quality (doc made for the sake of requirement, rather
> than for having something to say) and out-of-dateness (since the writer
> wrote it only typos were fixed) that I'm encountering across the specter
> while translating (haven't reached Amarok doc yet >:)

This makes sense to me. However I worry about all the uncompressable
PNGs bulking up the Git clones.

Ian