As originally announced I would like to have trunk based on Qt4 really soon now. For this I would like to branch off trunk this friday (and use the time till then to do an initial port of some more modules).

The translations were unaffected and would happen from the 3.5 branch. The 3.5 branch would still be an active development branch, but every change done there has to be done also in trunk. The actual schedule on merging might vary from app to app or even module to module, but that should be the goal. We can even make a public list of all revisions happened to 3.5 branch and strike off forward ports through a commit keyword (or some similiar mechanism).

But I think this needs to be done even before Qt4 is released. And it's no longer a completly uncertain adventure, but we know pretty well by now how much porting effort is behind Qt4 - but what we do not know is how well it runs. Getting konqueror to compile was done in pretty short time, but getting it to work for daily usage will still take a good while and we should as project should have good overview over it.

Everyone is free to stay and develop for KDE 3.5 as long as he feels like it, but everyone should be aware that the development for it needs to be ported to KDE4 without too much major pain or you're just asking for frustration.

KDE4 is the main target, KDE 3.5 development is defined as backport

OK, so how about dropping the idea of KDE 3.5 then? At the Akademy discussion KDE 3.5 was always discussed as "rest release". We really can't afford having KDE 4 be released in two years from now. And to get that done, we need all manpower we can get.

Take it as it is, but KDE 3.5 _is_ a step child and we can continue this "we need a KDE 3.X (where X is larger than the previous released)" discussion for years now. It just won't help us. We started with KDE 4 development - given fact. This means KDE 3.5 sees less development than any other KDE3 release - given fact. Now we have to make sure to find the balance between a) getting KDE 3.5 out at all and b) getting KDE 4 out in an overseeable future.

The basic assumption of the roadmap is that we won't be able to do feature work in two different branches, while porting one branch to Qt 4, because we don't have the resources to cope with the inevitable merging hell which would result from this. So we propose to concentrate on the 3.5 release and start Qt 4 porting and KDE 4 feature work when 3.5 is basically done.

i noticed people have touched kde4/kdebase/kicker which i really wish they hadn't. if you had to run a KDE3 linked kicker for another month or two i doubt it would've been a cause of great consternation, but making changes in kicker right now really doesn't mesh with the schedule i've set out, much as with the kdepim people

i think there is a compromise to be had in realizing that applications will start porting at different stages according to their priorities and schedules. so there will be some coordination needed here between "core" and "KDE applications". i think this also really helps to self-define the lines between "KDE core" and "KDE applications"

in any case, i'd recommend that "small apps" such as kdeutils, kdetoys, kdeadmin, etc. be brought over immediately, bar none. ditto with kdelibs/kdebase (yes, in spite of me dragging my heels for up to another 4 weeks with kicker ;) ...

kdemm probably will want to come over sooner than later too due to the massive changes they will need, but that's something best expressed by the kdemm developers.

as for the rest, i'd make it clear to them the issues and let them schedule their devel switch as it works for them. we should respect those wishes and not port the code on them in the meantime. many of these projects rarely or never touch kdelibs/base anyways and so for them following a moving target until it settles down a wee bit may not be worth it.

For now I merge over changes done in trunk and it's still pretty easy to merge as we haven't done too many changes that can't be easily reverted and redone (calling qt3to4 and get it to compile). And as I said: if your feature freeze is end of june, that's fine. You just switch working to 3.5 branch and leave trunk alone for the month. If you're done, you port it over in one go - either reusing or overwriting the changes done in trunk so far.

I'm also fine with whole of kdepim joining trunk development only in august. I even suggest we remove kdepim from trunk then and copy it back into trunk later. But that doesn't work for kicker. We really need a gradually ported KDE4 to test changes done to the framework. And we have to make sure we're not loosing overview - and if all KDE 3.5 development is going to be merged by me, we're going to loose overview. So I want a change in policy who is responsible for merging KDE 3.5 development into the then main development branch - I don't want to dictate a policy on when this needs to be done and not even how.