[Kde-scm-interest] [Proposal] Package splitting with thin meta-repos
Esben Mose Hansen
kde at mosehansen.dk
Fri Jan 29 14:00:05 CET 2010
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
* home grown solution sucks (If nothing else, do we really want to maintain
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
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
More information about the Kde-scm-interest