[Kde-scm-interest] Have we arrived to a dead end?

[Michael Jansen]

On Wednesday 17 February 2010 18:11:34 Thomas Zander wrote:
> On Wednesday 17. February 2010 13.45.28 Michael Jansen wrote:
> > You want to move the core of kde. Make a real plan. Describe how modules
> > 
> >  will be split.
> 
> done that some time ago;
> $ git clone git://gitorious.org/svn2git/kde-ruleset.git
> $ grep 'create repository' kde-ruleset/*
> 
> (no not providing the output, everyone here should have a checkout of
> that repo!)

That's nice and stuff. But the final git move will affect (or is it effect?) all kde devlopers. 
Playground, extragear, all modules. And i'm pretty sure that if the plans are not communicated in 
advance publically we will have hell break lose on the announcment at planetkde with "kde moves to 
git in 2 weeks and here is how it affects you".

So the general rules and state of the git move should be much more visible to all developers, 
lurkers, observers and so on out there. Just consider the people complaining about the phonon move. 
And i'm pretty sure there are some which haven't really noticed yet.

Even people participating here ask from time to time at which level will we split? 

Once again. I'm not opposed to git. I just see the move as a possible public relations desaster if 
done wrong. And wrong is a communication matter in my eyes. Not a technical matter. I'm neither 
qualified nor inclined to decide if spliiting more or less is better. There are more qualifier people.

 I personally would prefer a more detailed split but i guess that the configuration manager in me 
coming through. Much better to check dependencies and so. Much better to make hotfixes (just release 
kdelibs/kdecore instead of a complete kdelibs package ). But harder to achieve, harder to maintain 
for an open source project. And some of the pros don't really apply to a open source project. But 
something i could sell most of my clients pretty easily. 

> >  Analyse how  that affects the workflow of all devs,
> 
> Detailed before, it should not change at all (executive decision). Just
> give more options to those that want to use them.

Where. And less options by not making it easy possible anymore to start libs in one repository and 
then move it with complete history into some other. 

Btw. i personally don't care. With svn i had to use an server anyway to see the history so i do 
think the only part where i'm setback is that i can't easily find out where a lib comes from if that 
is not explicetly stated in the initial commit. So make a rule to provide that in move commits and 
i'm fine with it.

But communicate this loud and clearly. Everything you make publicly known now can't used for 
moaning, bitching and stuff after the move. And that will happen. It always happens when things 
change.

> >  Predict and explain how big
> >  repositories will get using git,
> 
> Much smaller than svn. KOffice including its 12 year history (80 branches)
> is 350Mb which you get if you indeed do a full checkout.
> A download of svn of the current tree (so without history) is some 200Mb.
> Sorry, no time to delve into the mail archives to find the previously
> published numbers.

Again don't tell me. Tell the world, put it on the planet, again and again.

> >  Explain how that affects and applies to
> >  kdesupport-oxygen.
> 
> If someone wrote the ruleset we could check the exact information. I can't
> do anything but speculate at this time.

Ok.

> >  Show us how it affects the work of the release- team.

> The Amarok people are in contact with the release team AFAIK. There are
> example scripts in use from them already. Its just different.

Given the split is done on our current module level i did not expect anything different.

> >  Get input from the distributions.
> 
> Asked several distro people (of various distros ;) on IRC and they were all
> perfectly fine with the transfer and preferred not splitting the repos.

Try to do it more public. All the discussion here leads to nothing because there is more or less 
only i guess, i think and i heard. Me too btw. 

Moving to git is not only a technical problem. It's a communication problem too. And the last part 
is probally much more important. At least imho. If the move should go smoothly it has to be brought 
to all affected, they won't come and inform themselve.

This is my last post on the git move matter and i conclude with "Communicate progress and state and 
decisions in the git move much better". It will pay back at the end. Consider the discussions and 
uncertainty here on this list. People here are interested and still confused and not fully informed.

Now raise the scale to all people out there having SUDDENLY (from their POV) adapt to something new. 
They know by now git is coming, but they have no idea what awaits them.

Mike

Mike