On Wednesday 26 May 2004 01:27, Joachim Werner wrote: > > KDE 3.2.3 is due in the next few weeks (last time I looked at the KDE > > release schedule), and the next PyKDE release should be ready very > > shortly after that. Phil has just released sip 3.10.2 (which the next > > PyKDE release will require) and hopefully the last sip4 rc (which PyKDE > > should work with), so sip 4.0 should be fairly close. Phil is also > > planning a PyQt update shortly. So everything should be in sync then.
> > If the last kdelibs 3.3rc is binary compatible with the final release, I > > could have PyKDE complete *before* the final. But then in theory, 3.3 is > > supposed to be binary compatible with 3.2, I believe. > > The problem in doing that is that the final rpms from SuSE, Mankdrake and > > whatever RH/Fedora is doing now are never compatible with "official" KDE > > source code (I get the source either from kde.org or uk.kde.org) - eg > > KFileShare::setShared on SuSE 3.1.x later rpm releases, similar stuff on > > Mdk or RH, QXEmbed with some distros, etc. It only takes one modified or > > deleted method to make PyKDE essentially unusable - PyKDE binds nearly > > every method in the kdelibs modules it supports, which most apps don't > > do. > > That being the case, I'd be shooting myself in the foot by doing a > > release ahead of the official KDE 3.3 rpms and not testing against those. > > Usually, I only build against the latest KDE on SuSE, but test earlier > > versions against Mdk and RH. > From the SUSE point of view I'd be fine if I could get hold of late > betas or release candidates a week or two after the KDE release that > preceeds our SUSE LINUX product. The enterprise products are always > based on the same code base, and we can make sure during the enterprise > beta phase that we become aware of any changes in KDE that would break > PYKDE. > That would mean that we can get things in sync during the beta phase and > release the latest KDE with the latest bindings. > From what you are saying this might work for the next SUSE LINUX. :-) I wouldn't mind doing this for any distribution. I can't promise to test against every beta/rc since both the download time and build time/build problems can be a lot of extra work. I can try to keep up with the rc releases and submit packages to you. Generally there are two problems: keeping PyKDE and sip in sync and keeping my tools in sync with KDE. We should be entering a phase where PyKDE and sip "get along" very well in terms of sip changes that affect PyKDE and KDE changes that require sip enhancements from Phil. Minor releases like KDE 3.2.3 should require almost no work on my part. Major releases like KDE 3.3.0 have required more work in the past because new C++ language features appear (nested template-based classes in kconfigskeleton in KDE 3.2) and the kdelibs hierarchy sometimes gets rearranged (for example kfile was folded into libkio quite some time ago). I'm expecting though that KDE 3.3 will be fairly easy as major releases go because both sip and PyKDE tools have improved a lot as far as C++ features supported. KDE4 may be harder, but there will probably be a lot of time to work out those issues. Most of the problems will show up in the early betas, so if I work with those, I should be able to have a final release fairly quickly. > I can't speak for the other distros, but I guess none of them release > their final products earlier than a couple of weeks after a major KDE > release ... > > I have enough problems when I do test (eg, the current problems with > > kdeui not finding kdefx on Mdk 10.0, which doesn't happen on Mdk 9.x, any > > SuSE after 8.1 or RH9.x). > If there are any automated tests we could run them as part of our QA > efforts. And of course we can provide betas to you ... The major issue is that the code base the distro uses has to match the code base PyKDE is written against in that every class/method has to continue to exist and every method has to have the same argument list (as well as the obvious - having a compatible sip/PyQt version). If that doesn't happen, one or more PyKDE modules won't be loadable under Python. So all that's necessary is to run the importtest.py script that comes with PyKDE. All that does is try to import each module. New methods shouldn't cause a problem - PyKDE just won't know about them. Repairing any problems is usually pretty trivial - comment out missing stuff, or modify an argument list. You could probably run importtest.py as part of the rpm install if you wanted to. That doesn't guarantee that PyKDE is 100% correct, but it does guarantee that everything is compatible and PyKDE is usable. As far as betas, I assume that involves downloading a few CDs worth of data. I'm on a satellite link and it isn't the most reliable bandwidth for downloads that large. However, Hans-Peter Jansen is very familiar with PyKDE build procedures and problems, and becoming familiar quickly with PyKDE internals, so he might be a good candidate to do that kind of testing - if he's interested. I'd support him as much as needed, of course. I hope my earlier post wasn't taken as being angry or flaming - I'm very interested in working with SuSE or other distributors, but the main concern is getting something usable and reliable to PyKDE users (which I haven't always succeeded at). Just let me know how you want to handle this and we'll see if it can be worked out. Jim _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
