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

[Tom Albers]

On Wed, 8 Sep 2010 13:52:08 +0200, zander at kde.org wrote:
> On Wednesday 8. September 2010 12.44.41 Tom Albers wrote:
>> And I again will point you that the fact that at least I was under the
>> impression that kde-scm-interest was a list about bikeshedding about
>> which scm we should choose. Which I really don't care about. I never
>> considered it the decision making list. I would be surprised if I were
>> the
>> only one. The list is not called kde-git-implementation at kde.org, which
I
>> would have joined right from the start.
> 
> The list was started to coordinate people with an interest in scm's. The

> result so far is that people that were like minded started doing work
and
> we 
> now have
> * a conversion tool
> * a consensus in those doing thework on how to split repositories
> * a nice progress on getting the conversion done.
> So calling this a bikeshedding list is not entirely fair, but it shows
we
> have 
> to do more work to make clear what our progress has been so far!

Don't twist my words please. I've indicated that I assumed the list was
about bikeshedding about the tool, and never considered it to be a decision
making list. I still find the name of the list confusing. 

I've respect for all the work that has been done by you and others.

> As such we, on this list, have a clear direction; the people that do the
> work 
> have chosen one specific approach and are grouping their efforts to get
> there.

I heard that before, and although I do agree with the general 'who does
the work decides', I don't think it applies 100% here. k-c-d was not
informed or I don't recall a call on blogs like 'hey we decided to go for
git, please come now to discuss the git details', i don't recall blogs
explaining the setup either. Things that influence how we as KDE work need
to be communicated well and people can not always be simply told to shut up
because they don't do the work. If things influence big parts of KDE there
needs to be a widespread support for the idea.

> The approach we have been following is different from what sysadmin is
> assuming 
> we have and is optimizing the sites for. If I understand the doc
correctly.
> Maybe sysadmin can write a proposal on what things would look like and
how
> we 
> can optimize things using the work already done. The exact list can be 
> extracted from the rules repo; 
> grep 'create repo' * | cut -d: -f2 | cut -d\  -f3 | sort | uniq

As said before, look at the document, the problems we touch and find
solutions for those.
 
> I'll attach the result as a text file.
> 
> Assume that the decision is what it was last week; to split as indicated
> in 
> the attached file. How would that work for our setup?

As said, if there was a decision (which is at least not what some people
told me), you can change a decision before it is too late. We have
indicated serious problems with the setup and we see more advantages in the
split-approach. It is our right and duty to advise you all to change your
minds. If we would not have done it, you would have blamed us after the
implementation 'why did you not say so before'.

I suggest and hope you drop the idea 'decision is made, i don't want to
think about changing', and try to see what problems we face in implementing
it. Imho it is a once in a lifetime decision and it should be taken with
care. Having no energy to look at it from a new angle is no good reason to
not do it.

We also have the idea that the discussion in the past was also based on
the though that we would loose the hierarchical structure by using split
repositories. Now sysadmin has decided to launch projects.kde.org, this
structure can be given this way, which means previous arguments in the
discussions are now invalid. 


> As you guys seemed to not have been aware of the actual plan we have
been 
> executing (as indicated in the document by the assumption that
> kdeextragear 
> would have been one module) it would be nice if you could write another
> email 
> that builds on top of our work and gives hints on small changes that may
> make 
> everyones life better.
> At least that would avoid discouraging people that already put in a lot
of 
> time and have gone though this discussion too many times already.

Again, we advise you to go for a split approach, if the list does not want
that, it is fine. Just solve the problems we address in the document and
accept the technical consequences it will have. To turn this around: don't
discourage us to write such documents in the future, I think it contributes
to the discussion and is therefore valueable.

It's like making a decision between buying 2 new cars, you made a
decision, go to the shop to buy it and the salesmen tells you there are
technical advantages and disadvantages for the car you want. You can either
fix the technical issues as good as you can or choose to ignore them and
accept consequences or change your mind. But you seem to blame the salesmen
that he is telling this to you.

Best,
-- 
Tom Albers
KDE Sysadmin