> [: 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. 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. 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 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 >:) Thankfully, this is again not influencing the Scripty implementation, as arbitrary paths can be given in the register file. > [...] The tarball scripts could just download the translations from > Vertimus rather then commit them to Git at all. But this is a decision for > kde-i18n-doc, not this list. :) Exactly, this is a matter of later concern, but do note that Scripty will have to continue having commit access to the repo and branches given in app's section in the register file, to push there updates to .desktop (and possibly other) files. Vertimus-like or whatever approach is purely a translator-side part of the equation, that would again be decoupled from how app maintainers will fetch translations (e.g. Scripty could even commit totally everything concerning translations into the app's repo, not only .desktop files). I've mentioned Gnome and Vertimus only to recognize that practically there is little novel in the outlined concept, that it has already been used elsewhere. -- Chusslove Illich (Часлав Илић)
pgpQ9mTfvtVqH.pgp
Description: PGP signature
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
