Future of KDE Development

[Cornelius Schumacher]

On Monday 14 February 2005 16:07, Stephan Kulow wrote:
>
> 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.

That's exactly my feeling. Doing kdelibs 3 based feature development in 
parallel to Qt 4 porting and kdelibs 4 development sounds like a 
nightmare, because of the following reasons:
- Lack of resources. I doubt that there will be many people being able 
to work on a kdelibs 3 branch as well as on a kdelibs 4 based branch. 
For me personally I know for sure that I won't be able to do this.
- Merging hell. Merging Qt 3 based features into code already ported to 
Qt 4 will be, well, challenging. Renamed classes and functions, Qt API 
changes and new concepts like the model-view classes or the new 
iterators will make this very difficult, error-prone and 
labor-intensive.
- Library development can't be done theoretically. We need the 
applications using the libraries for making the right decisions about 
the API and the implementation of the libs, we need them as test cases 
and we need the modules participating in the libs development, so that 
code that belongs to the libs, but now is in the modules can be 
integrated into the libs.

An additional problem I see is that Qt 4 isn't finished yet. The 
Trolltech roadmap says that Qt 4 won't be released before June, that's 
still four months ahead. I have tried the previews and the beta and my 
experience was that it's nice for testing and playing around, but 
nothing I would like to use for serious development (which is quite 
natural for prewies and beta releases).

So what about the following proposal:

Next release after 3.4 will be 3.5. We use the four months till the Qt 4 
release for implementing outstanding features and usability 
improvements, integrating new artwork from kde-look contests, improving 
documentation, completing translations, moving to subversion, 
experimenting with a new build system, but don't do any Qt 4 porting 
yet.

The day Trolltech releases the final version of Qt 4.0 we branch and 
freeze CVS (or rather subversion then) for the 3.5 release and start 
porting the HEAD branch (libraries and modules) to Qt4. Then we proceed 
with the alpha release scheme Stephan proposed until we have a KDE 4.

Not doing 3.5 and 4.0 development in parallel avoids the problems I 
mentioned above and has the additional advantage that the Qt 4 port 
could be done as concerted effort by all developers, so that we quickly 
get to a state where everything compiles and is usable for development 
again. Maybe something like a "porting meeting" could be held to do 
this in the most efficient way. Maybe also Trolltech could help with 
this, the Qt developers won't have anything to do anymore after the Qt 
4 release, after all ;-) 

-- 
Cornelius Schumacher <schumacher at kde.org>