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

[Albert Astals Cid]

A Dimarts, 26 de maig de 2009, Ian Monroe va escriure:
> 2009/5/26 Chusslove Illich <caslav.ilic at gmx.net>:
> > First of all, "moving to Git" is under quotes because it's, in my view, a
> > misnomer for what should really be done to properly reorganize the
> > things, such that we do not set ourselves up for a similar trouble in the
> > foreseeable future, and provide even more flexibility right after its up
> > and running. What we need is separation, decoupling of translators' and
> > programmers' facilities, such that one does not influence the other, save
> > through a well-defined internal bridge which few people can maintain. The
> > idea is that translators can pick their own VCS (and/or something else),
> > and likewise maintainers of an app or a complete core module.
>
> 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.

Well, everyone keeps saying "We are loosing developers because of SVN", can't 
I extend that to "We are loosing developers because of CURRENT_VCS"?

>
> > While I personally don't like messing with Scripty as it is further and
> > advised against it, it *can* be made to work as above, i.e. to make
> > things no worse (or marginally worse) for the few overall i18n
> > maintainers, *and* introduce *no* changes for translators in general.
> >
> > It's conceptually simple. Modify Scripty such that a random app, with its
> > random separate repo and VCS (be it Subversion, Git, etc.) can just put a
> > few lines in a particular Scripty's register file, which will map it's
> > repo locations/branches to what Scripty should fetch, extract, and commit
> > to. For example:
> >
> >  [amarok]
> >  section = extragear
> >  subsection = multimedia
> >  vcs = git
> >  repo-base = git://foo.bar.kde/amarok
> >  ui-stable = src at branch_2_0
> >  ui-trunk = src at master
> >  doc-stable = doc at branch_2_0
> >  doc-trunk = doc at master
>
> Outside of the "vcs = git" line (since this should be assumed IMO) the
> above makes a lot of sense to me.
>
> We are going to have to have some way for project maintainers to
> specify which branches should be translated.

We already can specify which branches are translated with our current setup, 
this would be just a different way to define it.

Albert