Hi Kevin and Frank, On 08/03/2014, at 11:02 PM, Kevin Krammer wrote: > On Saturday, 2014-03-08, 21:47:07, Ian Wadham wrote: >> On 08/03/2014, at 6:43 PM, Frank Reininghaus wrote: >>> 2014-03-08 4:38 GMT+01:00 Ian Wadham: >>>> While we are on the topic of testing, how much testing is done of >>>> KDE's cross-platform and cross-desktop implementations? >>> >>> Unless the people who prepare the Mac packages test them, the only >>> testing is done by you and by other users, >> >> So what I am hearing, in answer to my question, is "No testing by the KDE >> development team". > > I think this would only be the case if the two groups of people, KDE > Developers and KDE-on-Mac packagers/users, were non-overlapping sets.
I think they probably are non-overlapping sets. There *is* a KDE Mac mailing list, but I receive only a few posts per year from it, as compared with several a day from Macports. > That might of course be true, but also a bit uncommon. Packaging efforts for > all other platforms is at least to some extend handled by people who are > either users of the packaged software or KDE developers using the respective > platform. Part of the problem may be that, until recently, it has been difficult for a KDE developer to just buy a MacBook Pro and set up a dual-boot or virtualised Linux system on it. But now it is quite easy … :-) I aim to have a go, once I have Palapeli for KDE 4.13 put to bed. OTOH it has always been easy to set up Linux on an IBM-compatible PC. >>> most of whom unfortunately >>> seem to be either unable or unwilling to file useful bug reports and >>> help to debug the problems. >> >> Most of the problems that occur are in building and configuring >> packages across various Apple machines and versions of OS X, from >> several years ago to the present day. The Macports team provide about >> 12,000 packages and do a wonderful job of answering the users' queries >> on MacPorts Users <macports-us...@lists.macosforge.org>. The users >> usually file their bug reports (about builds, etc) in the Macports bugs >> database. > > Which sounds very similar to how it works on Linux. Do they also have similar > policies of "upstreaming" bug reports of things not caused by "local" changes? > >>>> Just in the last week I have seen cases of a guy on Apple OS X who could >>>> not build kde4-baseapps >>> >>> Which version of kde-baseapps? Has this guy filed a bug report? >> >> He filed one at https://trac.macports.org/ticket/42673. He did not nominate >> a version of KDE, but it would have to be in the range KDE 4.10 to 4.12. At >> this stage, it looks as if the problem could be compiler-related. > > In this case it seems that the report has been addressed correctly, i.e. an > error in packaging reported to the packager. Yep, but more of a difficulty than an error really. The user in question had a version of OS X that was three versions and about three years behind current and Apple has a habit of making quite radical changes … :-( >> If KDE developers cannot or will not test a release on some version of >> Apple hardware and OS X, what right do they have to offer it as a >> cross-platform and cross-desktop system? > > Do you mean all KDE developers or some? As I wrote above, I would be > surprised > if none of the packager nor users of KDE applications on Mac are KDE > developers. > > But "all" doesn't seem realistic either. I guess I meant KDE as a group that releases software. Clearly some of that software is intended to be useable on Apple OS X and MS Windows because it contains conditional code for those environments. In that sense, I would say the KDE group is "offering" KDE software on Apple OS X and MS Windows, just as they are offering it on Linux, so they ought to organise some basic functional testing in conjunction with each new release. I do not know which group of KDE guys should do it. Clearly it would be uneconomical, in cost of hardware alone, for every KDE developer to test his or her software on every platform. But I think it would be reasonable for two or three guys to do it. Much of the portability of KDE apps depends on kdelibs4 and Qt 4. On the whole, the performance of kdelibs4 on Apple OS X is very good. I have only found two problems in two or three years. One is current, but the ball is in my court … :-( … the other was compiling and linking with the Clang compiler, which has now been resolved. As I said before, the problems of applications failing on Apple OS X after being built, seem to come from the KDE infrastructure, which would have to work slightly differently in an OS X environment. I am thinking of plugins, KParts, daemons, DBus traffic, etc. Maybe there is just some Shell environment variable that is not set right. Who knows? Another source of problems is the excessive list of dependencies in KDE (see attached). Many of these are irrelevant in an Apple OS X environment, but still add to the difficulty of porting and the time and space costs of downloading and installing KDE apps. This may also account for the "1 Gigabyte for one game" problem on MS Windows that I mentioned before. >>>> And it would be nice to have some regular testing ... :-) >>> >>> I understand that quite a bit of regular testing is being done by you >>> and your friends. >> >> No, not testing, they are mostly just attempting to build and *use* stuff. >> If they fail, I think they just go and try some other package … :-) > > Well, that is some for of testing. > Valuable testing if the failure is reported, sophisticated testing if the > test > is repeated regularily. > > Very similar to other platforms, no? To me, testing is a purposeful, directed activity that is (or should be) carried out by programmers or an independent testing team. The idea that letting software loose on innocent users is a form of testing is anathema to me. Of course, users can and do come up with input combinations or new ways of using the software, which the programmers/testers do not foresee and which can throw up bugs. That is why we must have bug-reporting, however hard we try to forestall every side and corner case. Cheers, Ian W.
kde-app-dependencies
Description: Binary data
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
