Forming repos by plugin type or code domain? (was: Re: KDESDK->git: joining submodules in a singlerepo?)

[Friedrich W. H. Kossebau]

Hi Nick,

Am Samstag, 2. Juni 2012, 12:54:16 schrieb Nick Shaforostoff:
> is it possible to have po, ts and xliff strigi analyzers in lokalize git
> repo?

Sure it is possible. It's thankfully more a question if we/you want it to have 
them there :)

And I guess there are also good reasons why there should be just one repo with 
all things related to translation (catalogs), which are:
* Lokalize
* the strigi analyzers for the catalogs
* the thumbnailer plugin for po (new in kdesdk/thumbnailers/po)

Even if that leaves just one analyzer in the "normal" strigi-analyzers repo, 
the one for "diff" files. Perhaps that could be moved to the Kompare repo, so 
bundling the code about diffing?

Forming the repos in a document-oriented way, i.e. what the source code is 
dealing with, looks like a superior approach than e.g. forming by plugin type. 
As both developers and users/packagers usually more care about some 
data/document type than all kind of plugins for a given system, so they just 
want the code/packages which deal with that data/document type.
And tendencially it would also group code with the same dependencies, while 
grouping by plugin type only has one common dependency, the plugin interface, 
and that lots of dependencies, whatever all the plugins cover.

Only from a conversion-rule-writing POV it is the worse solution :)

What are your opinions?

Cheers
Friedrich