On Thu, 2 Jul 2009 5:43:04 pm Stefan Majewsky wrote: > Am Donnerstag 02 Juli 2009 01:04:16 schrieb Tom Albers: > > I think this is up to the maintainer of kdegames to decide which is Matt > > Williams. If you are the maintainer of Kolf, I trust Matt to consider > > your opinion. > > > > If Kolf 2.0 is what is developed in trunk currently and it will be > > shipped in kde 4.4.0, there is no need to move stuff to unmaintained. > > That's for real dead apps. We can remove applications, there is no need > > for an extra RC in that case. > > > > Again, the module maintainer should deal with this, together with the app > > maintainer. > > I forgot that the release-team usually does not follow the discussion here: > In trunk is Kolf 1.9, its maintainer has resigned about a year ago. Around > this time, I started work on Kolf 2.0, which is in playground/games/kolf-ng > at the moment. > Hello Tom and release team,
I do not think you are in possession of all the facts. There is nothing wrong with Kolf 1.9, currently in trunk/kdegames, except that it currently does not have a maintainer. A lot of work was done on it by the previous maintainer and our artists to bring it up to KDE 4 standard. Kolf 1.9 works perfectly fine with Qt 4.4 and has been working fine for several years through successive releases. It fails horribly with Qt 4.5, which was introduced into KDE 4.3 at a rather late stage in the release cycle. Two other games (at least) are also affected by regressions in Qt 4.5, but not so drastically. I think there is a strong case for holding over Qt4.5 until KDE 4.4 and no case for dropping Kolf 1.9, which is an innocent bystander. Unfortunately, the KDE Games team are in no position to resolve the problem by patching Kolf 1.9 or diagnosing what is wrong with Qt 4.5 ... we simply do not know enough about either and have not enough time to learn. We tried to get help on kde-devel and kde-core-devel, but there was no response on either list. I base my belief that you should consider holding over Qt 4.5 on industry experience going back several years. As I commented at the beginning of this thread: "Where I come from (professionally, before I retired), the order of priority, from highest to lowest, was: 1. Preserve functionality and reliability for end users. 2. Preserve stability, functionality and reliability of supporting software for application programmers. 3. Upgrade to the latest supporting software, but only after extensive regression testing. These rules were based on the greatest good of the greatest number ... N users > N application programmers > N system programmers." This is perhaps the reverse of "coder decides", but it is the way the industry has been developing since the early 1970s and I have been a part of that in various roles in projects on which I have worked - as a core developer, as an application programmer, as an end-user representative, as a manager --- even as a release-manager ... :-) I feel strongly about these principles and I think they are important to the future of KDE. Please consider well. All the best, Ian Wadham, Melbourne, Australia, Oldest KDE Developer (?) P.S. Tom, I think I met you at Akademy 2008. _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
