[Kde-scm-interest] Sysadmin advice regarding Monolithic vs Split repositories.

[Tom Albers]

On Tue, 7 Sep 2010 13:03:28 -0700, Chani <chanika at gmail.com> wrote:
> -would moving a project between monolithic repositories really be all
that 
> bad? you say that the kdereview workflow would "no longer be possible" -
> but 
> iirc, we were told before that moves would be possible, merely harder.
> What I'm concerned about here is plasmoids: even if we go for split 
> repositories for apps (which I agree would make for a much easier and
less 
> surprising kdereview workflow), it may be a bit excessive for every
little 
> plasmoid to have its own repo.
> Perhaps for little plasmoids (and other odds and ends that will
inevitably 
> crop up) we could move them and leave/copy their history?

I leave this for experts on git.

> -you mention pros and cons of monolithic, but not split repos... perhaps
> these 
> are just two sides of the same coin, but I'd like some more detail on
the 
> disadvantages of spilt repos.

Yes, the pro's and cons are the same, but with different headings above it
:)
In the rest of the document we outline advantages and disadvantages of
both.

> -I don't understand the fuss over reviewboard. currently, reviews are
sent
> to 
> groups, independent of where the code is located: for example, a plasma
> review 
> request could be for code in kdelibs, workspace/plasma, kdeplasmaaddons,

> playground, or elsewhere. Are you suggesting automating (and therefore 
> changing) these reviewer groups, or just the underlying modules? (I
would 
> assume the latter, but want to be clear here :)
> Also, 90% of the reviews are old cruft that someone forgot to close, so
> imho 
> you'd have no problem just discarding them when a move happens. :)
> anything 
> that's not abandoned could be resubmitted.

Ok, some clarification: currently we have reviewboard projects for
everyone who requested one. One for marble, kmail, plasma, etc. In the new
setup we want to centralize the management of the systems. That means there
is a 1-to-1 mapping between gitolite repositories, redmine projects and
reviewboard projects. That means in the monolithic approach we would not
have a 'kmail' project anymore in reviewboard, but only the general
'kdepim' project. Kmail review requests should be submitted to the 'kdepim'
project on rb. That means that there can only be 1 recipient.

The alternative is either split-repositories where this problem does not
occur or loose the 1-to-1 mapping we would like to have. But that does not
make it less surprising for the visitor, as he has cloned the main module,
but has to file his review requests to the submodule. We already see that
it sometimes causes confusion on the current reviewboard, as not all
'submodules' are present on rb (in the worst case you only find out just
before submitting the review request).

> -can the namespacing be set up so that someone could one day write a
patch
> to 
> redmine to hide redundancies in naming? :) that'd be a nice touch.

Yes, we have to find a way that's human readable and machine parsable
there. Maybe konversation|website or konversation_website. Ideas are
welcome.

 
> -how does each option affect release engineering and packaging? I don't
> see 
> that addressed anywhere in here. :/

We tried to focus on the sysadmin pov. But I hope the tarballs will stay
the same (although the toplevel cmake will probably change to only list a
bunch of subdirs, instead of the build foo). The release team scripts need
to change, but then, they have to anyways. Which means work for them, yes,
-- 
Tom Albers
KDE Sysadmin