Hi,
I was browsing the mailing list when the "I wish to complaint" mail. As already mentionned, there are probably two factors which cause people not to test so much the release candidates and the beta: 1. They have an important project working, and don't want to try to make it not work with a beta version 2. It is tedious to test a beta. The way you can address that is : 1. Make it as easy as possible for people to test the new versions. It should be easy to download, easy to install, easy to switch for one version to another. So provide binary packages if you can, explain clearly how to make two pyqt version coexist, how to switch from one to the other, what the common problems are with this setting. You must provide some documentation on the website to encourage people to do it. I notice that a PyQt faq is missing from the website. Are there really no common problem at all installing and using PyQt ? If it takes two hours to compile PyQt, and 10 minutes to install, and people know that they can switch in 10s from one stable version to an unstable one, you will encourage people to test. 2. Compilation time : you must make your possible to reduce it. Compiler cache (http://ccache.samba.org/) might help. Or the other proposed trick with all the cpp in one file. 3. Packaging : The top is if you can provide binary packages. You probably haven't access to all the possible platform, but by providing enough packaging info, you can probably encourage the users of this list to package for you on their distro. Again, if it takes two hours for them to find how they have to package the stuff, they probably won't do it. So it must be as easy as possible There is a proverb that says that if you reduce the difficulty of using your software by 10%, you double your number of users. I like the spirit. 4. Releases: don't do too many releases. ESR's "release early release often" work when you have a list of dedicated users compiling on cvs every day and watching the development closely. It doesn't seem to be the case for PyQt/PyKDE. Because it takes time to test a release, users are not ready to do it every month. Let them breath. If your release is "fix bug in module xy and on platform zz" and your users do not use module xy nor platform zz, they won't test this release. So I suggest to do bigger releases, with more interval between releases. This makes people more curious about the release (what has happened since 4 month on PyQt ?), you have bigger updates to show, users may dedicate some testing time. I find KDE's pace of release very good. One major release every 4 to 6 month, and bug fix releases two month after standard release. 5. Announce it: If you need more tester, tell it. Say it on the website, publish an article on dot.kde.org. This of course works better with big releases. You can ask publicly every month people to test your release candidate. For the distribution problem, have you tried to get in contact with the packager ? Hope this can help. Philippe _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde