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

Wed Feb 17 20:20:17 CET 2010

I'm with Michael here.

I (just like many others) started losing interest in the discussion some time 
ago, when the feeling was that most of the times people kept bringing on the 
same issues over and over again without getting anywhere.

I feel there is a communication problem here. The decisions we're taking will 
affect all of the KDE development environment, and I feel that the more people 
will go on with the tasks, the more other people will join this list and 
repeat history. It is clearly a wrong approach, especially given KDE 
philosophy.

Here's my small proposal on how to go on:

- In this list we're lucky enough to have a lot of people who know a lot about 
git, and most of the kde developers who already did the switch. So let's make 
a detailed plan, structure and whatever, like Thomas shown a pair of messages 
ago.
- Done that, prepare a well structured document, which would include pros, 
cons, changes, solution to all possible issues, and whatever else, and start a 
discussion in a place such as kde-core-devel.
- As soon as the idea will be approved (maybe through a votation?), start 
working on the plan and make it real

At the moment the sensation is that anyone who's doing any kind of work is 
wasting his time, due to the fact that the plans either change by the minute 
or are not widely known. So I think the starting point would be getting full 
(or almost) acceptance between kde developers and packagers.

But to do this a decent and possibly very detailed document is needed. I think 
this is the only and critical task now.

On Wednesday 17 February 2010 20:09:48 Michael Jansen wrote:
> 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
> _______________________________________________
> Kde-scm-interest mailing list
> Kde-scm-interest at kde.org
> https://mail.kde.org/mailman/listinfo/kde-scm-interest

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100217/2dba31fe/attachment.sig 