[Kde-scm-interest] Package splitting

[Thomas Zander]

On Wednesday 27. January 2010 14.01.28 Thiago Macieira wrote:
> If we have split repositories, then we lose atomicity. Period.

Fully agreed.
Guess why I'm against splitting modules. :)

> This includes for example having kdelibs separated from kdebase. If
>  someone  adds a new feature to kdelibs and then uses it in any
>  application, that already requires non-atomic updates.
> 
> And no one is suggesting making one huge KDE repository with everything in.

We are mixing things up here; Indeed nobody was suggesting to make one big 
repo. What we *were* talking about was splitting up things like kdegames and 
kdeutils.

Going from the concept of having one module like kdegames *with* an included 
libs dir to having many git repos is more exactly what was on the table.

The point of atomicity is a really useful thing there, people can develop on 
one game and pulling all commits has zero effect on compile time as he's still 
working on only that game.
It does have the excellent side effect that if there was an update in the libs 
dir of that kdegames module cmake will trigger a recompile in the libs. Which 
is essential for development on the game itself too.

> So forget atomicity. It's not an argument.

In contrary; atomicity is the number 2 argument against  splitting up the 
seperate kde modules.

A counter argument that [some part in kde] doesn't have atomicity with [other 
part] would lead to it being perfectly fine to completely loose all atomicity 
falls under the bell-curve argument.
It doesn't apply to the subject on the table.
-- 
Thomas Zander