policy change related to kdelibs snapshots

[Aaron J. Seigo]

On Tuesday 11 July 2006 18:13, Gary Cramblitt wrote:
> operators (pause, resume, stop/delete).  Do you think I'll be able to do
> that with qsystemtray or ksystemtray?

ksystemtray still provides you with an actioncollection ... and you can create 
your own actions ... so i don't see a problem here.

> > and finally, seli and i laid out a plan for a new, improved mechanism to
> > replace most of our systray usage in kde4 based on seli's ideas and
> > conversations we had in the last 2 years.
>
> It would be nice to know what those plans are, but I'm guessing it is too
> early for you to do that.

perhaps ... i'll wait until there's some code to show ... nicest that way =)

> > thinking about what might help things ... do you think it would help you
> > if a message was posted to kde-core-devel with a subject line such as
> > "[API] <classname>" with the API change noted in it when such changes are
> > made?
>
> If you mean adding a CCMAIL to the commit, probably not.  I read all the

no. that would be silly. i mean an actual "this is the API change" mail that 
really explains things.

> code.  Something part-timers like me don't have time for.  Furthermore,
> finding out about the change at commit time is too late.

i disagree. this is a way to document changes that have happened which is in 
the long run (e.g. 6 months from now) infinitely more useful than a 
discussion about what might change. add to that that a lot of changes are 
decided not on this mailing list, and that that's perfectly ok. it seems some 
people want every API change discussed here and while it is important to 
discuss and have API changes reviewed i don't think this mailing list 
is -always- the appropriate/best place.

take a look at the akonadi, k3m or kde four core meetings for examples.

a post-change message would give us a way to document all changes once they 
are decided on no matter how that happened. of course discussion could 
continue, and that's why it's called revision control.

> > what exactly does your "KTTS user realtime management GUI" require
> > interaction-wise?
>
> It provides a menu with "Pause",  "Resume", "Stop/Delete", and "Configure"
> (which launches KCMKttsMgr in a separate process), "About", and "Help".  
> It also provides a balloon status message on mouse hover.

this is still provided with ksystemtray (and qsystemtray for that matter).

> > just as i would be remiss to second-guess the design of ktts without
> > actually delving into it, i would suggest it's not helpful for
> > application developers to do the same to the library developers.
>
> Since my dbus concerns are not relevant to this thread, I'll post about
> them separately.  My main point is that there was no transition.   We
> talked and talked about changing to dbus (at least a year now, but it seems
> longer). When it finally happened, it happened suddenly with zero
> opportunity to evaluate.  Wasn't there *some* intermediate implementation
> possible? Couldn't the dcop objects have stayed in the library for at least
> a few weeks?

this is your perspective. the people working on dbus worked on it for a *long* 
time, there was a lot of evaluation and they did have a whole separate branch 
for dbus in kde4. we even used dbus in kde3 for hal interaction for hotplug 
support. now, you may have not used the kde4 dbus branch or been involved in 
the QtDbus API definition or the usage of it in the first apps or in the 
hammering out of bugs at trysil, but that's ok. you don't have to be involved 
with every decision. nor do i. learning to let go and trust each other a bit 
here is good. in part that means realizing that this project is bigger than 
each of our individual horizons (and skill sets) and there will be things 
happening that we are not aware of.

being made aware of all of them would end up sucking all of our time simply 
reading about what others are doing. eventually we'd all do nothing ;)

this is, btw, why i suggest a means of doing a summary email rather than 
insisting on "everybody's invited" sessions.

> > exactly why what you suggest was not done. not to mention people would
> > just hold on to their dcop stuff and dbus would remain half baked and
> > we'd ship a mess with kde 4.0.
>
> If the QtDBus implementation had been added with an announcement that "dcop
> will be deleted in 3 weeks", I believe most would have cooperated,
> including me.

i distinctly remember messages about the dbus branch. at least i was quite 
aware of it (and i didn't even have it checked out)

> I am not saying that face-to-face and irc should not be done.  I am not
> saying that changes should not be made.  I am not saying that "permission"
> from the user community is necessary before changes are made.  I am saying
> that it would be better if the decision makers (and implementors) kept the
> rest of us better informed as to what is going on.

i would agree with this. the question for me is "what does this look like 
without grinding the project to a halt or encouraging bikeshedding?"

> > that would be cool. just need people to keep it up to date. good luck ;)
> > with the emails to kde-core-devel, this could be somewhat automated. and
> > i think it's unecessary to know when kdelibs devels =will= do someting,
> > it's more important to know that if you update svn from a july 1 checkout
> > to a july 10 checkout what will have changed.
>
> Either kdelibs devs *want* app devs involved in the process or not.  From
> most of your reply, I have the sense that you don't want our input.  OK,

let me turn it around then ... should i and everyone else follow everything 
you do in kttsd? perhaps you could discuss every change you make to it since 
it's the speech support for the whole desktop? no, that's silly. there's a 
balance to be struck.

if you wish to be involved with libs dev, there's a lot of ways to do that. 
this discussion is about app devs who don't want to keep up with libs devel 
but want relative stability with well known break points in stability.

> Is it so terrible to ask that you at least keep us informed about what is
> going on, especially when it involves significant api changes?

i think there is a ballance between "making every change take 3 weeks" 
and "keeping people appraised of the situation". how many people do we need 
involved at which stage of library design and development?

is it important to have everyone involved at the inception of a concept?
at an early implementation of it?
at the "mostly, probably stable" implementation of it?
at the final release?

i think the first and last are absurd, and the third option is probably not 
terrific. for huge changes it's great to have a number of eyes on it. but 
even then that number needs to be managed to not become cumbersome. once 
there is an implementation then i do think we need as many people pounding on 
it as possible. and then we can engage in another round of implementation, 
iteratively, based on that feedback.

for a worst case scenario, look at the infamous systray example: it was 
decided that it was unwanted and it took all of one svn revert to fix that. 
cost? my time (and annoyance). not yours.

i get the impression you are feeling that changes are communicated (which is 
why i suggest something more active that the KDE4PORTING.html file) and that 
any change is somehow set in stone rather than a work in progress. is this an 
accurate reading?

at which point do you think app devels who are actively writing libs code 
enter the development cycle?

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060711/313b6839/attachment.sig>