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

[Matt Williams]

On 29 January 2010 13:00, Esben Mose Hansen <kde at mosehansen.dk> wrote:
> 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.)

I wonder, has anyone started any communication with the Git developers
about the problems we have with submodules? Or even generally how to
solve our layout problems?

> * 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.

One thing we all seem to agree on is that playground, kdereview and
extragear will all be 'split' such that we will have one repository
per application or library. Perhaps it's worth writing this down in
stone somewhere so we don't lose track of the things we have consensus
on.

> 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.

The only problem I see here is how to move a game from kdereview to
kdegames while keeping its history. I've been lead to believe that you
can't incorporate a repo into another one while keeping all the
history. This is also a problem when we want to move libs or apps
_out_ of a module (into playground/unmaintained or another main
module).

> 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.

I agree with this. The community is not defined in anyway by the
layout of the code in the SCM.

-- 
Matt Williams
http://milliams.com