Future of KDE Development

[Stephan Kulow]

Hi!

[Disclaimer: this is a very important thing, so I would like everyone having 
something to say to stay strictly on topic. If you want to discuss some 
subtopics in detail, open a new thread. Having said that, remember I'm not 
the only list moderator.]

KDE 3.4 is almost done and I try to make sense out of my conflicting thoughts
about how to continue. So here I am starting the discussion. I have talked 
with quite some of you already on topics related to this, but it deserves to 
be publically visible.

At first I would like to say that I was release dude for the third release now 
and I'm feeling loss of motivation from time to time, but so far I feel that 
continuing to bring in my experience for the job is better for KDE 
than having someone new and possibly more motivated start from scratch. Due 
to the dedicated help of Stephan Binner and others we managed to get releases 
out quite well. So this is what I would like to formalize in the future: 
KDE releases aren't done by single persons but by a team, where one of them 
has the final word. 

Now to the more important part: There are a lot of ideas floating around what 
to change for KDE4 and there are a lot of ideas floating around when KDE4 
will be released. And I think we should bring them together to create a 
common roadmap. But let me list the things we're facing in the future:

- Change to subversion
- Qt4 port
- Windows port
- Build system change (as related to the above and more)
- Switch to standard gettext 
- DCOP changes (DBUS was discussed)
- Change of soundsystem layer
- Further cleanup of our API (there are already tons of KDE4 comments)

This all sounds like a lot and it surely is. Still no-one would like to have  
KDE4 in late 2006, but the earliest possible. And even if there is no stable 
release for users, we would like to have a version that works good enough for
our own daily use (at least some do, some prefer to run Xnest :)

And on top of that, not everyone wants to ditch the KDE3 code base and start
working on KDE4 right away, but would prefer a KDE 3.5 application release,
which would delay KDE4 even more due to split of man power.

Now the question is: how to get all these demands together. This discussion 
surely reminds me on the one we had in Ludwigsburg where I claimed that a KDE 
3.4 would delay KDE4. Fortunately this can no longer be hold up as the delay 
is meanwhile more because of the Qt4 delay (which we still face - let's hope 
it's worth it).

Fortunately I can say, that subversion will open soon for performance and 
acceptance testing and if that passes, we will migrate our CVS as fast as 
possible (different thread!), so this should be done as soon as KDE 3.4
is released. Most scripts are also already ported to svn, kde-i18n scripts of course 
will take a bit longer after that.

Now the windows port kind of happened side by side to normal development, so I 
don't see a big issue with that one. If we won't make it perfect before KDE4 
(without having tried to build KDE CVS on windows I can only guess it's not 
perfect yet), no-one will miss it per se. And if we finish it, it will be an 
additional plus. No time issue here from my perspective.

I would like to clean up the build system majorly and surely would like to 
finish it before KDE4. I have tons of ideas and would like to basically start 
from scratch - what tools would we have choosen if we had started now? Don't 
say qmake, I won't believe you. Anyway: different thread, but surely a lot of 
work, that also includes the risk of scaring people away. Answer this: what 
is more scary: the current build system or the idea of throwing anything you 
know about the current build system away? 

The switch to gettext is long overdue, which might require that we drop our 
enhanced i18n versions. But hopefully, someone/me can add what we might 
need to the upstream gettext, if it's not there already. We'll see: different 
thread.

DCOP/DBUS has already been discussed and is for sure a challenge to be done 
right. But it's largely independent of Qt4 from what I understand. So it can be 
included together with the sound system change in the last point: Changes of 
our API in general.

This is for me the biggest variable in both time and stability. I would like 
to see quite some applications/APIs rewritten to be more advanced in general, 
but nothing stops us from doing a lot of this work in a KDE 4.1. But for that 
KDE4 needs to clean up the API to be as flexible and powerful as possible. 
Not an easy task and nothing we should try to do as quick as possible but as 
good as possible.

Problem is that designing/implementing a good kdelibs requires applications to 
make use of it so you can see if it works as good as you intented to. So 
enhancing kdelibs is no singled out process. I can't really imagine the 
perfect way to do that in parallel with a KDE 3.5.

Anyway, let me draft a roadmap:

* KDE 3.4 is released
* we migrate to subversion (this will require some downtime of development per
  module that we will interleave)
* we create a bunch of branches:
  -  KDE_3_5_BRANCH (or /branches/KDE/3.5 :) for a future KDE 3.5 release.
     When it's clear that development in there stops as people are satisfied/bored with it 
     and rather spent time with Qt4, we make a release on short notice (e.g. two months
     after we agree to release) - latest christmas 2005. 
  - new_build_system_branch - as long as nothing compiles, I would like to
    have it branched. I guess you agree.
  - Qt4_branch for modules beside kdelibs. HEAD of kdelibs will be Qt4, but 
    all other modules should branch off Qt4 porting as long as it's not
    settled.
  - DBUS_branch/noarts_branch/whatever. As long as it's in early development,
    it should stay away from HEAD. This way we might have an at least half
    way working HEAD at all times.
* We remember a nice rule of the past: incompatible changes in HEAD (i.e.
  experimental branch merges) are only done between monday and wednesday.
  With subversion we're supposed to have much better control over branches, so
  we should make use of them whenever we can.
* We will release an alpha1 whenever one of the things in my list is finished
  and the sources compile. We do that every 6 weeks at least after the first
  alpha1 till we reach a state where we can claim we're done through the
  basics and then we write down when to feature freeze, etc. This is all way
  too early to say now.

So I can very well imagine we finish the initial Qt4 port around the same time 
KDE 3.5 is due, so it might be a perfect match.

Now a last word of warning: I expect this to be a pretty long thread, so 
please keep the signal/noise ratio as high as possible and add as much as 
input as you like, but be prepared to put your money where your mouth is.
I want to get this thing started and not talk about it for another decade.

Greetings, Stephan