[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-scm-interest
Subject:    Re: [Kde-scm-interest] Sysadmin advice regarding Monolithic vs
From:       zander () kde ! org
Date:       2010-09-08 10:21:38
Message-ID: 201009081221.38916.zander () kde ! org
[Download RAW message or body]

On Tuesday 7. September 2010 18.04.40 Tom Albers wrote:
> Our advise is to use a split repositories approach.

Reading the pdf I'm left with the impression that you guys didn't read the 
archives of the scm ML.  All of the disadvantages for a monolithic approach 
are incorrect and rebutted before.
All the disadvantages to the split approach are also missing.

I'll give a very short overview of what I recall from the top of my head
* moving applications from kdereview/kdeextragear/main-module.
marking this as 'impossible' is odd as the approach and implementation 
(rulesets) we have now show clearly that kdereview and kdeextragear are not 
monolithic. There simple is *no* moving there going on.
An app would start as a single repo and get upgraded by metadata. So the 
existing proposal and the new proposal agree. This should have no effect on the 
split apprach of the main modules at all.
Moving a finished app into a main module (like kdeedu) is possible and not hard 
to be done with retaining history. There are tools to do that and the only one 
that has to re-clone are the ones following the previous separate application 
repo. They now have to clone the kdeedu one.
Bottom line; there was never any history rewriting in the approach as 
advocated by Thiago and me and others.

* The disadvantage to increasing the size of clones is just not there; compare 
network traffic for a git clone to an svn checkout and the size is marginally 
bigger with full history. Numbers have been posted previously. (can't be 
bothered to look them up now).
With the proposal it actually gets bigger; see 2 points down.

Ignored disadvantages;
* having each app in koffice as a repo and doing a refactor means you need to 
push to multiple repositories. Managing multiple repositories is not something 
that git is good at and as a result you will have to do multiple pushes 
yourself. This has a real-life effect on daily operations.

* repositories get bigger if you put multiple applications in there, no 
surprise. They will on the whole get smaller as git compression works better 
with more data. So having 10 repos of 10 apps or having 1 repo with 10 apps 
then the one with 1 repo will be smaller over the network and on disk.

* the splitting has shown the concern that people that want to use one kdeedu 
app will no longer benefit from finding the other ones also in the same module. 
This makes helping out with development less KDE like where people are invited 
to jump in and fix stuff.  If they don't have the source they are less likely to 
do so.

* we have rules for non-split repos. They work mostly. The proposal means we 
have to start over.

* rule writing for splitting individual apps is a *lot* harder than writing 
per module. So I expect this change at this time to cause a minimum delay of 6 
months.

* I am discouraged that this one mail caused a lot of people to change their 
minds and just change direction. Which effectively means 2 years of consensus 
building and rule writing is thrown away. I don't think I can stumach this 
restart of effort and still help out with the conversion.

-- 
Thomas Zander
_______________________________________________
Kde-scm-interest mailing list
Kde-scm-interest@kde.org
https://mail.kde.org/mailman/listinfo/kde-scm-interest
[prev in list] [next in list] [prev in thread] [next in thread]