[Kde-scm-interest] [Proposal] Package splitting with thin meta-repos

[Esben Mose Hansen]

On Friday 29 January 2010 08:59:04 Oswald Buddenhagen wrote:
> great - you replaced git's suboptimal builtin submodule handling with a
> home-grown scripted solution which fails for everything but checking
> out (and possibly updatating). what a progress ...
> 

Let me gather the arguments here:

* svn external sucks. (For me, most importently, history is lost)
* git submodule sucks. (Well,  it works fine for a completely different 
usecase.)
* home grown solution sucks (If nothing else, do we really want to maintain 
that stuff?)

My own (work) experience tells me there are 2 ways that actually work. 

1. Big repositories --- one repository for several applications. More or less 
how it works today.
2. One repository, one program or library. This works, but requires version 
checks.

In my humble opinion, the good answer lies somewhere in between. So here is 
what I would do:

1. Keep the existing modules except review and playground as-is.
2. Split up playground and review into solution 2: One repository, one 
program. These would probably depend on one or more libraries from the 
modules, so CMake checks for these would be needed (I believe CMake has a 
"right" way to do this). Once these are made (for the new applications), 
maintaining them surely is no worse than bumping a number somewhere (this 
application now required kdegames >= 4.5.56.

In this way, we won't get a "big bang" split up + migration, which is maybe 
too ambitious, and we would still get the ability to move application from 
review+playground. And the atomicity problems goes away. As for dependency 
hell, I believe one "lib" for each module + kdelibs would be a reasonable 
amount to check for.

As for the community-is-a-module, I think that could be maintained by a 
script, but better by a website, a mailing list and so forth.. after all, the 
community is the people, not the code.

Just my 0.02€ :)

-- 
Kind regards, Esben