policy change related to kdelibs snapshots

[Benjamin Meyer]

On Sunday 09 July 2006 9:50 pm, Stephan Kulow wrote:
> 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

Why not simply drop the snapshot libs?  Any major changes should have their 
own branch like liveui current has.  When big changes are intigrated it can 
be announced ahead of time that things will be broken for a day or two (some 
porting and testing should have already been done).  For any minor changes, 
the guys who commit to libs should port the rest of kde first.

-Benjamin Meyer

-- 
aka icefox
Public Key: http://www.icefox.net/public_key.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060710/26e96aa0/attachment.sig>