[Kde-scm-interest] Sysadmin advice regarding Monolithic vs Split repositories.
Chani
chanika at gmail.com
Tue Sep 7 22:03:28 CEST 2010
On September 7, 2010 09:04:40 Tom Albers wrote:
> Dear Scm-interest,
>
> As promised, the people behind the sysadmin team would like to give advice
> regarding the monolithic vs split repositories issues. We have tried to
> stay away from the community/social issues and focus on the technical
> consequences such a decision involves - such as how to setup the different
> services we will setup.
thanks for the report. :)
I like the comment about rsibreak ;) there certainly are advantages to split
repositories...
however, there are still some things I'd like clarification on:
-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?
-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.
-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.
-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.
-how does each option affect release engineering and packaging? I don't see
that addressed anywhere in here. :/
More information about the Kde-scm-interest
mailing list