Reorganizing the KDE organization (Re: Redefining kdelibs and kdebase)

[Cristian Tibirna]

I shall start by saying that this is the most comprehensive and clear/lucid 
answer to the original post of Benjamin. Aaron manages to single out the 
essentials as well as the  premises (correct ones as well as not so correct 
ones). I thus take the liberty to subscribe to the majority of his answers. 
With a poking-out exception (read below)

On 29 August 2005 04:38, Aaron J. Seigo wrote:
> On Saturday 27 August 2005 02:45, Benjamin Meyer wrote:
> > -Biggest issue facing KDE is portability
>
> i actually disagree completely. the biggest issue is not portability but
> code modularity and maintenance. 

[cut]

> > The maintainer should typically be the only commiters for
> > each component.
>
> i think this needs to be stressed a bit more:
>
> 	every item in Components *must* have a maintainer at all times
>
> yes, this would be a restriction we are placing upon ourselves, but it's
> time we took true responsibility for our base environment. right now we
> treat kdelibs so poorly that it's a joke, and most of that is because of
> lack of stewardship over these critical bits. a bug or an error in
> Components effects every single KDE app. that said, maintainers SHOULD:
>
> 	- triage defect reports
> 	- manage community input (patches, primarily) to keep things moving
> forward in a non-chaotic method
> 	- keep up with the state of the art outside of KDE (e.g. if you are doing
> KWebService you need to be aware of what's happening with SOAP, AJAX, etc)
>

And why doesn't it happen now (and will never happen, IMHO, save special -- 
specified ahead -- conditions are met) ?

Because imposing strict responsabilities and defined workload requires 
compensation. Yes, a mundane salary. Unfortunately, I don't see near 
prospects for enlightened companies or renaissance millionaires to agree of 
subsidising the necessary very dedicated KDE developers so that kdelibs 
technologies gain assigned maintainers doing what you (and common sense) say 
they have to do.


Onwards now. I changed the subject because the initial thread diverted very 
much.

About the initial thread, some that might remember me discussing this topic 
(or related ones) 4-5 years ago might ack. that I am advocating a drastic 
streamlining of what is actually called KDE, so that only essential libs and 
the workplace components stay in place and be called KDE, while all the rest 
goes to independent projects with (as much as possible and/or useful) 
independent goals, schedules and release timings.

Yet, I disagree profoundly that such a code reorganisation has anything to do 
with integrating KDE apps in other (completely non-interesting) platforms. 
Our main goal is KDE as a whole not some KDE bits spread thin on alien 
contraptions.

I came lately to realize though that not a code reorganisation is essential 
but a reorganisation of the project (community, resources, policies and 
statement of goals). Our community/project is still organised quite similarly 
to what we had while still pursuing Mathias's initial dream (c.a. 1996). That 
dream was fulfilled with KDE-2 IMHO. We are now far beyond that initial 
dream. 

The picture of this required reorganisation is still not completely 
crystalised in my head so I'd be highly interested in what others think 
("you're full of c**p" comments are acceptable but I can't guarantee that 
their handling might not ensue piping to /dev/null)

Thank you.

-- 
Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org