[Kde-games-devel] Re: Move to git

[Frederik Schwarzer]

On 01/02/2011, Aaron J. Seigo <aseigo at kde.org> wrote:
> On Tuesday, February 1, 2011, Frederik Schwarzer wrote:

Hi,

>> With split repos it will be way easier to include new games to the
>> module or to move games from the repo to extragear or playground
>> without messing with history.
>
> and much harder to build. unless everyone moves to tools like kdesrc-build
> and
> lets that automate it for them, you can very much expect the # of people
> testing the various games from master to drop as the effort needed to keep
> all
> those separate repositories and builds up to date goes up.
>
> some things are absolutely simpler and more straightforward by creating 37
> app
> repoes and then another for the libraries. building the games and keeping up
> with what gaes are available is not one of them.
>
> if you all decide to go the split route, please, please, please ensure you
> have a sensible build strategy in place otherwise you will lose a large
> portion of your testing and casual contributor base.
>
> as one non-representative data point: i doubt many (if any) of the patches i
> have contributed to kdegames over the years would have happened if i had to
> track 38 repositories instead of 1. those patches may not be large in number
> or value at the end of the day; you need to decide if casual "drive by"
> contributions are important to you. you should consider the ease of people
> getting involved with dev for the first time.

I do not think, "drive by" contributors are scared by 37 separate repos.
I think the natural thinking happens to be game-based, not
mosule-based. So if there is a potential contributor, he will think
about contributing to Knights or KPat and not to kdegames in general.
But yes, we need some easy way to build the whole module.

On the other hand we exclude a (likely very small) group of people
behind a quota-regulated network. At my gitlfriend's place, I would
never be allowed to clone a 100M+ repo, because she only has 1G per
month. After that the connection goes down to 56k.

What I want to say with that example is, that there are problems with
both approaches. Most of them seem to be inconvenient but not fatal,
though.

About the scaring-away of new contributors, I think, it is a problem
in both ways. There will be some scared-away by many small repos that
are harder to build as a whole; some will not like one big repo
either. So in my opinion it's not the "doing this we will scare away
all the contributors" but rather a one way scares away one group of
contributors; the other another group.

As for the artwork split. Can anyone scetch an example layout about
how it is meant?
Would it be this way? (I would not like that)
- games/
        bomber/
            src/
            doc/
        bovo/
            src/
            doc/
        ...
- artwork/
        bomber/
            themes/
        bovo/
            themes/
        ...

Besides this detail, which I might have gotten wrong, I still am more
in favour of the split approach because the problems there seem to be
more solvable (yes, someone still has to do it :)) that those with the
monolithic approach.

Regards