policy change related to kdelibs snapshots

[Albert Astals Cid]

A Diumenge 09 Juliol 2006 21:50, Stephan Kulow va escriure:
> 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.

Does that mean EVERYONE (kdelibs and app devels) should use bleedingedge or 
only libs devels?

If it is only libs devels i see a problem with syncing my changes adding 
features to trunk/ and changes of libs that happen in bleedingedge/

If it is everyone that should use bleedingedge why not simply use trunk?

Albert

>
> 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