Reorganizing the KDE organization (Re: Redefining kdelibs and kdebase)
tibirna at kde.org
Tue Aug 30 05:36:21 BST 2005
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.
> > 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
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
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
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)
KDE developer .. tibirna at kde.org .. http://www.kde.org
More information about the kde-core-devel