Merging some repos?

[Daniele E. Domenichelli]

On 22/03/12 03:39, Dario Freddi wrote:
> This approach has also multiple advantages, such as:
>
>   * We can decide which commit each submodule will point to, so it's
> safe ground for testers
>   * Or we can allow people to fuck this and just get master of each repo
>   * Qt already did the hard job for us and we just have to adapt our scripts
>   * This approach preserves modularity but still allows to group quite
> efficiently some/all repos.

* If we find out that this approach sucks we can easily go back to the 
multiple repository approach
* If one day some packages will enter in any kde "main" package we just 
need to import the add the submodule there and remove it from here.


Since Dario is supporting me on git submodules I propose an alternative 
(but I still believe we should talk about this later, perhaps at Akademy):

Instead of making several packages, we make a single "kde-telepathy" 
meta repository (yes kde-telepathy, not ktp :P). Inside we add some 
subdirectories (libs, handlers, config, utils, whatever, etc.) and 
inside each subdir we put the real repositories.

Then we find some cmake guru to write the cmake stuff, so that you can 
build just one repository by cloning it, or build the whole metapackage
  * handling dependencies on your KDE version
  * handling dependencies on the libraries you have installed
  * handling dependencies on other modules, etc.
  * allowing you to configure which packages you want to build
  * disabling "experimental" packages (i.e. packages from playground) by
    default but allowing you to enable them using cmake variables. (In
    this way it makes sense to release them and let users and distros
    choose if they want them.

Then we write some scripts for bumping version in every submodule, 
tagging and make tarballs for releases (we should release both the 
single packages and the "full" package)


Daniele