policy change related to kdelibs snapshots

[Michaël Larouche]

Le July 9, 2006 15:50, Stephan Kulow a écrit :
> 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

So if I develop in kdelibs you mean that I need to maintain TWO trees of 
KDE4 ?

I find that overkill and I'm afraid that having many copies of KDE4 would 
cause a management and merge nightmare.

If we need a more dynamic way to develop KDE4, then we should drop 
kdelibs4_snapshot. Maybe that will bring more peoples(i.e applications 
developers) trying to stabilize kdelibs.

In resume, I'm against it ;)

-- 
Michaël Larouche
KDE developer working on Kopete, Gamefu(KDE), Solid...on dial-up :P
--------------------------------------
Website: http://www.tehbisnatch.org/
MSN/Email: michael.larouche at kdemail.net
IRC: irc.freenode.org/DarkShock on #kopete,#solid,#gamefu,#plasma
Jabber: darkshock at myjabber.net