policy change related to kdelibs snapshots

[Stephan Kulow]

Hi!

I think the way we do trunk development at the moment has failed.
A compiling KDE is more the exception than the rule and most of
the time I have time for KDE4 development I need to patch something
before I could even start looking at applications ;(

This _has_ to change and soon. If I may remember that we're doing
this "qt4 porting" for over a year now and so far KDE4 does not bring
any new features afaik. It only adds new bugs. This won't change as long
as we can't get KDE to build more often. And we can't simply ignore all 
modules beside libs and base.

So while we shouldn't miss the opportunity to cleanup applications that are no 
longer maintained and should rather be dropped than ported, we shouldn't
drop all porting efforts onto the application developers. 

So I would like to propose that we use bleedingedge for all modules currently
in KDE/ and changes to trunk/kdelibs/ should always come with a porting of 
bleedingedge to it. Otherwise kdelibs development will continue stay out of 
touch with applications. I kind of doubt the ksystray change would have 
happened the way it did if a closer look was taken on how the applications
are using it.

Now that build system and dbus change are mostly behind us, we should
way more concentrate on getting unique features into the desktop and
applications. 

I could even imagine giving up on snapshot/bleedingedge at this time if just
it came with a KDE4 you can work on (and more importantly: in) at any time.
I'm very well aware that not everyone is able to recompile all of KDE within
an hour, so my requirement as it may block some from active kdelibs 
development, but in the current situation we're requireing every application
developer that wants to do weekend hackery to learn about new APIs every
two weeks and I'm 100% sure that those caming up with the new APIs are
more likely to port without bugs.

And no-one says you have to port all applications on your own, but it should
be the responsibility of those changing that the rest follows. 
For one: I would like to know how kcoloredit and koffice are supposed to 
compile without kxyseparator being installed.

Greetings, Stephan