[Kde-scm-interest] Re: RFC: git move proposal; "duolithic" kdegames

[Frederik Schwarzer]

On 02/03/2011, Stefan Majewsky <stefan.majewsky at googlemail.com> wrote:
> [crosspost kde-games-devel + kde-scm-interest]

Hi,

> I've been thinking about the Git move again. I'm still in favor of the
> monolithic approach for organizational reasons, e.g. I really like
> Aaron's argument that a single repo makes drive-by contributions from
> outside itch-scratchers easier.

I failed to understand this argumentation from the very beginning.
In the end I blame different ways of working (maybe thinking) for that.
However, since more and more apps are migrated to git.kde.org, I see
one advantage of that infrastructure in my way of doing things. If I
see some problem (mainly while translating), I have only one
information: the name of the application. With this I first of all do
a "git clone kde:appname" and it tends to work more often week after
week.
But I see a similar kind of potential approach for "drive-by contributors".

How do they realise they want to change something? What I can think of
is, they are playing a game or two. Let's say Knights and KPatience.
If they know about the kdegames module, they look there and only find
one of the games since Knights currently is in Extragear. If they know
other per-app repos, they try kde:knights (which works) and kde:kpat
(which would not work). So far for people that are at least a bit
familiar with KDE. Completely external contributors do not have any
expectation about how stuff is organized. So they probably just do a
google search or even find projects.kde.org and search there. But
still I cannot wrap my imagination around the thought that they would
search for "kdegames" or "games". For me the only (or even the vast
majority of) inspiration for working on something can be t ohave seen
the object of interest. And that would be a game in this case.

I remember at least one discussion in the beginnings of the Git
transition, where the KDEGames module (back then a bit more active)
had an agreement on the split approach, in case they were to be asked
(that wasn't certain back then).

It would be nice if we at least try to weigh both approaches with some
strategic analysis. There are problems in both ways that have to be
solved (or swallowed as a somewhat acrid pill). We should write these
problems down and list possible solutions.

As for the splitting of data files. The SVN repo will go away
eventually. The kde-wallpapers (will) have the same problem. What are
the plans there?

I mean, in general, there are modules that already split/partly
split/data'ed out/and so on. Can we have someone who is observing
those modules' transition to comment on the downsides/upsides of their
approaches?

Regards