Moving 3.5 development into branches/KDE/3.5

Aaron J. Seigo aseigo at
Tue May 31 00:14:37 BST 2005

On Monday 30 May 2005 03:48, Maksim Orlovich wrote:
> > to make PIM development productive is to not require us to fiddle with
> > moving
> > targets (qt 4/kdelibs 4), bc issues, merging and all other related
>  stuff.
> On the flip side, this means you'll likely have to port to kdelibs that
> look very different from current ones, rather than porting in stages. Pick
> your poison.

yes, it's a trade off:

port now and leave 3.5 more or less behind, incrementally keeping up with a 
moving target which is pure hell if you are an app developer

port later and suffer a lot of changes all at once, which is just hell. (as 
opposed to "pure hell" ;)

> > Either that, or throwing in more manpower to do the 'real' work. Dealing
> > with
> > merging is just wasting *very* precious time.
> Which is why people can't reasonably expect the very few people on KDE4
> porting team to keep up with the 3.5 development all on their own.

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 

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. 

there also ought IMHO to be a "final date" set down (not necessary to do it 
today, though) whereafter apps either have the choice of porting over or not 
being included in KDE4.

Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list