New Prosal [was Re: policy change related to kdelibs snapshots]

[Aaron J. Seigo]

On Tuesday 11 July 2006 7:30, Dirk Mueller wrote:
> separate branch (Kmessagebox broken? yay! KSystemTray changed in a very
> incompatible way all at once? yay!).

*sigh* this is how rumors get started. ksystemtray's primary (perhaps only 
meaningful) change was that you couldn't get middle clicks anymore and if you 
were doing fancy event capturing you'd have to rethink what you were 
doing.... but both of those things are abuses of the systemtray, particularly 
the latter, and should probably be done using applets.

this is OT for this thread, but i'd like to be properly represented here. =)

> > My most important requirement at this point is that library developers
> > are required to make sure their API changes make sense (in either porting
> > the apps for themselves or writing good porting guide material on use
> > cases).
>
> The most important point is that we have a structured way on when to merge
> refactorings (most importantly when ther was a branch where a snapshot of
> KDE compiled against, and when the API change was reviewed). Didn't we talk
> about API reviews and kdelibs teams forever on the meeting and now its all
> forgotten again? Great to see that the new kind of thunder didn't even last
> one week.

stop energy alert!!!!

*woot* *woot* <--- klaxons! (just got them installed, neat, huh?)

ok .. now that i've annoyed you with cuteness, let's talk without innuendo. we 
want API reviews, the question is how and when to do them. the trick is to 
strike a balance between agility / ease of involvement and quality / 
structure. i agree this is an important topic. perhaps another thread would 
be useful to discuss this rather than make this one thread meander in too 
many different directions?

now back on topic:

personally ...... i don't see the problem with app developers simply not 
updating kdelibs so bloody often. keep your libs and other modules old and 
just work on your own stuff, and update everything every few weeks. a little 
self-discipline would go a _long_ way here.

app devs are asking for kdelibs people to have all this structure and 
discipline, which is good. but i don't see a reciprocating commitment from 
many of the app devs. (i think the koffice devs are a nice exception here; 
kudos boys 'n girls in KO land =) ... we could probably help them out with 
this discipline by providing an API change timeline which could be as simple 
as routine messages to k-c-d noting API changes. these should include what 
changed, why it changed and who was involved (e.g. "who reviewed this 
change"). it would be trivial via a script to go from that to a little 
timeline that could be uploaded to a website somewhere. thoughts?

-- 
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/7db0c89a/attachment.sig>