On Mon, Mar 10, 2014 at 7:06 PM, Ian Wadham <iandw...@gmail.com> wrote: > > On 09/03/2014, at 8:23 PM, Kevin Krammer wrote: > >> Hi Ian, >> >> On Sunday, 2014-03-09, 17:33:12, Ian Wadham wrote: >>> 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. >> >> Ah, interesting. >> This makes it very different from all other platforms (various Linux >> distributions, BSD, Windows, mobile platforms), where some of the packagers >> are also KDE developers. > > Macports grew out of something Apple did in the early days, mainly directed > at getting any kind of free open-source software onto Apple Mac. There are > also Fink and Homebrew doing similar jobs. > > A lot of the emphasis is on GNU utilities and languages such as Perl, TCL > and Python, plus some Science packages and Fortran, used by real scientists, > free database packages (mysql, mariadb, sqlite, etc.). > > The Macports have fantastic Unix/BSD and sysadmin skills, but not much > knowledge of KDE. The KDE porting team does a good job and are currently > at KDE 4.12.2, but they make not much attempt to adapt or convert KDE to run > smoothly in the Apple OS X environment. One guy goes a bit deeper, with > KMyMoney4, and is in touch with the developers, I think. I help him too, > when I can. Both of us rely on KMM4 to run our finances ... ;-) > >>>> 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. >> >> The main part of the problem, i.e. Apple at least officially requring special >> hardware, still remains. >> I am not sure it is feasible to assume anyone would buy a second computer >> just >> to satisfy some hardware vendor's lock-in phantasies. > > I think your prejudices are showing, Kevin ... :-) Actually Apple Mac > hardware is bog-standard Intel underneath and OS X is BSD UNIX > underneath. When I am doing KDE development, I might as well be > sitting using a Konsole or XTerm window. The problem up till now > has been EFI booting, but there is now a package called "rEFIt" that > can set up partitions and the boot area to boot whatever you like.
Whilst there is nothing particularly special about Mac hardware now, one is only allowed by the Mac OS X licensing to run it on Apple hardware. It is therefore impossible for KDE to provide Continuous Integration support without Apple hardware. For the same reasons, it isn't possible for individual KDE developers to test their work. As far as I know, one cannot virtualise Mac OS X, or if one can, it must still be done on Apple hardware. > > I am old enough to remember why Apple went the way it did in 1982 > with the Lisa and Mac. It was to keep control over configuration and > minimise support problems. IBM with their PC, by contrast, let the > genie out of the jar and look where Microsoft and even Linux users > are today ... > > At an educational group I belong to there is a monthly PC Users Group, > all these people my age struggling with MS Windows, security, viruses, > malware, how to set up a network, etc. There is no real need for an > Apple Users Group ... > >> However, those who own Apple hardware seem to either not use OSX or not use >> KDE applications on OSX, otherwise there would be an overlap in the >> users/developers group. > > Users yes ... developers no. I think I am the only KDE developer on Apple > and that is only for applications --- and games at that. I am not a "core" > developer. I might be able to do that stuff. I used to before I retired from > the workforce, but now I just like to program for fun ... :-) > >> Do you know if the Mac packaging group is just building the software or if >> they also run the automated tests? > > I don't know for sure, but I think they just build, sometimes patching to > overcome incompatibility problems and build failures. > >> My assumption until this thread was that OSX as a target platform was handled >> similar to how all other were handled, i.e. a group of people with deeper >> understanding of the platform's peculiarities would build the software, fix >> eventual problems and upstream those fixes. Doing the latter through persons >> within the group who are KDE developers. >> >> My updated understanding is that the group packaging KDE software for OSX >> does >> not have any members who are KDE developers, > > I am not certain of that, but it is probably so. > >> so either fixes are not developed >> at all or are lost between KDE releases. > > Well, they propagate fixes for build, compilation and dependency problems > and have a rather sophisticated system for doing so, but that is local to > Apple > OS X and is not finding and fixing any bugs in KDE or Qt AFAIK. > > Of course, as a KDE developer working on an Apple MacBook Pro, I am > connected to KDE mailing lists, bugzilla and the git repositories, so if > I find and fix a bug, the fixes propagate just as if I were working on Linux. > >>> Another source of problems is the excessive list of dependencies >>> in KDE (see attached). >> >> A lot of that seems to be purely build dependencies, not something an end >> user >> would be affected by. > > Well I am. You'd better believe how long it takes to go through all > that Nepomuk stuff on a limited bandwidth broadband connection, > let alone compile it, if any of it has to be compiled from source. And > those dependencies have caused lots of problems in Macports in the > past and they used to cause me endless problems when I worked > on a Linux system. > >> And some of the dependencies look "wrong", e.g. the X11 ones. > > They might be, but Apple is rather ambivalent about X11. It's an > ongoing issue. Some packages require X11 on Apple, such as > Gimp and Inkscape. It looks as though libsdl does in this case: > and strigi depends on ffmpeg which depends on libsdl. > > But my point is why the hell does KGoldrunner, an arcade game > of which I am the author, depend on Nepomuk and Strigi? I never > use them and I never will ... Denny Crane ... :-) > > That is what is "wrong" IMHO ... :-) As the Americans said at the > start of the War of Independence, "No taxation without representation". > I see those dependencies as a "hidden tax" on every KDE developer > and user ... :-) > >> Based on my previous understanding of the OSX packaging efforts I would have >> assumed that at least the latter would be taken care of during packaging, but >> according to the new information it seems that the group's assumption is that >> upstream will improve the situtation at some point anyway. >> >> Since that doesn't sound very reasonable I am sure that I am still missing >> important pieces of information in there somewhere :) > > Yes, probably we do have some missing pieces. I do not have the whole > picture. > >> In the long run it might not be viable to target a platform with a community >> that is either incapable or unwilling to engage through contributions. > > Well, I hope you will consult the Apple FOSS providers (Macports, Fink and > Homebrew) before you pull the plug ... They are decent, hardworking people > like you and me ... :-) ... and they are dedicated to keeping FOSS alive in > the Apple OS X world --- all FOSS, not just KDE. > > Cheers, Ian W. > > P.S. I see from your signature you are a developer mentor, Kevin. > > Would you be able to mentor me while I try to get a handle on some of the > problems with running KDE apps in an Apple environment? Like my first problem > will be why plugins sometimes work and sometimes not, in KDE on Apple OS X. > > > >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe << Thanks, Ben >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
