policy change related to kdelibs snapshots

[Gary Cramblitt]

I am less concerned about the frequency of kdelibs updates or the process that 
incorporates them.

For me, the greater concern is that changes seem to come from nowhere and 
without warning, or a plan, or instructions on what I'm supposed to change as 
an app developer.

Partly, this is because I'm in US and when I come online in irc, most devs are 
logging out.  So I miss whatever discussions are occuring there.

For example, it appears that a decision was made to remove KSystemTray from 
kdelibs?  From my perspective, this "decision" came from nowhere.  Why was 
this decision made and what am I supposed to use for my KTTS user realtime 
management gui instead?

Don't misunderstand me.  I understand that changes are necessary.  I 
understand that I'm on the bleeding edge and expect my app to break 
regularly.  But I'm not sure the needs of application devs are being fully 
considered.

Its a tough problem because the more unstable kdelibs is, the fewer 
application developers there are to give you feedback.  How many app devs are 
there?  Other than myself, a few KOffice guys, and a few kdepim guys, I 
suspect there aren't many right now.

From my perspective as a part time app dev, there is a disturbing tendency to 
discard functionality before a good alternative is fully ready.  For example, 
I have concerns about dbus.  I fear we may have made a mistake in jumping to 
an immature dbus architecture.  IMHO, dbus is a step backwards from dcop.  I 
would have preferred to see a parallel implementation for a bit longer to 
give the community time to evaluate the pros and cons.  I realize that too is 
very difficult.  There needs to be a working implementation so that devs can 
code against it and evaluate it, but how do you maintain two IPC 
implementations in a single library?

What I'd like to see is a process where someone proposes a change, announces 
it on kde-core mailing list, stating reasons for change, alternatives to be 
used instead, and stating when the change will occur.  Something like 
this:  " I plan to remove KFoo from kdelibs because 1) it is lame, 2) it is 
broken, 3) coolo says it is bad.  Instead, please use KBar.  I have added 
KBar to the library for you to start migrating your apps.  Instructions are 
in kbar.h.  If nobody violently objects, I will remove KFoo on nn aaa nnnn ( 
two weeks from today)."  The parallel time period should be appropriate for 
the level of disruption the change requires.  A minor change could be 
implemented in a week; a major change for a month or two.  Before removing 
KFoo, the implementor should give some consideration to whether adequate 
feedback has been received, especially from app devs.  Silence isn't 
necessarily a good thing.  It may mean that nobody has had time to evaluate 
the change.

It would be really nice if there were a single place (wiki?) where I could see 
all the upcoming changes listed on some sort of calendar.  "Hmm, I see they 
plan to remove KSystemTray in two weeks.  My app is using that.  What's up 
with that?  I better look into <fill in alternative> and provide feedback 
before it is too late."

Lest anyone get wrong impression, I really appreciate the hard work devs 
have/are putting into kdelibs.

Thanks for listening.
-- 
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
http://accessibility.kde.org/developer/kttsd/index.php