On Tue, 7 Sep 2010 13:03:28 -0700, Chani <chan...@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 _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest