On Friday July 11 2003 10:19, Jonathan Gardner wrote: > The problem really is that right now, PyKDE development is > having a hard time keeping up with PyQt/sip development. This > is due partly because the maintainer PyKDE (Jim Bublitz) is > busy, and partly because the maintainer of PyQt (Phil > Thompson) is not.
> I mean, everyone has this problem of maintaining two or three > seperate versions of software as the software goes through > major upgrades. That is unavoidable. The problems with sip, > PyQt, and PyKDE is that we are going through major revisions > quite often at this point, and unfortunately, Jim is not able > to keep up with Phil's rapid pace, in addition to the short > upgrade cycles. The upgrade cycles are part of it - KDE also releases pretty often. The other part is that there have been a lot of PyKDE "infrastructure" improvements (tools, unit tests, examples, etc) some of which went into the 3.5 release and delayed 3.6. > The first solution in my mind is that we need to open up > development of PyKDE so that it can keep up with PyQt. This is > being done by Jim right now, so everything is good there. I'm not sure what you mean here - if "open up" means more frequent releases, I'm aiming for that. On the other hand, if it means more participation in development (other than testing, bug reports, patches, examples, etc), that's is pretty difficult. I'd love to have half a dozen people working on PyKDE, but the problem is that it's not modular like kernel development. The PyKDE development process is pretty monolithic and inter-related. I don't see any way to fix that at the moment, and that (or me) is the biggest problem. > The second solution would be to branch and maintain the > earlier releases of PyQt and sip. People won't have to upgrade > to a new version to get a minor bug fix they need, and so they > won't be trapped waiting for PyKDE to come out. This requires > more bodies and time, and both seem to be short in supply. It > also helps to have fewer versions of sip and PyQt to maintain. >From the user's standpoint, it's going to take as long to apply a sip or PyQt patch as it would upgrade to a new version (and isn't much help for rpm versions). The problem here is really PyKDE (or again, me), and that's where the fix needs to be. > A third solution would be a sip 3.7.1 that works with PyQt > 3.7.0, 3.7.1, and 3.7.2, if you know what I mean. I think this > would alleviate a lot of issues in all three packages. This is > a lot of work to implement, even more work to maintain, and > probably not a good idea at this point. However, maintaining > backwards compatibility is a worthy goal of all software > projects. The problem is that something has to give somewhere in this whole thing. It's feasible to maintain support across a wide number of versions of Qt, KDE, Python and gcc, but it's not as easy to maintain compatibility across sip versions (depends on the changes). Again, if PyKDE stays in sync (which it *should* be possible to do), the problem mostly goes away. > I will add that the barriers I see to people adopting sip, > PyQt, and PyKDE are the problems of getting the right versions > to play together, while also getting the latest bug fixes. It > is outright frustrating at times. I myself stick with the 3.5 > supplied with RedHat 8, just so that I can stabilize my > development. I think all three suggestions above should help > to lower this barrier. I agree - I'd add that PyKDE lagging both sip/PyQt and KDE isn't a good thing. > These are just my opinions, based on what I have seen and > heard. I hope they are challenged and corrected as > appropriate. Actually, I think you're trying to be too nice. The problem is definitely with PyKDE and me. If I thought a different maintainer would fix the problem I'd be all for that, and if I thought getting more development help would be a solution, I'd be asking for that. Most everything *should* be in place to solve most of this - I just didn't allow for a large amount of user input (which I'm all in favor of) and then got stuck doing a lot of other stuff. I should have got the 3.6 release out first and *then* started patching, and that's what I'll probably go back and do (3.6 and 3.7 first in one release, and then the patches, bug-fixes, etc). I can post what the PyKDE development process involves if anyone is interested. It's quite different than a normal C++ or Python project. Jim _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
