[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: What to test for 4.13?
From:       Kevin Krammer <krammer () kde ! org>
Date:       2014-03-09 9:23:11
Message-ID: 3745739.aU2yNbohzB () persephone
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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.

> > 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.

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.

> OTOH it has always been easy to set up Linux on an IBM-compatible PC.

Sure, but I don't think developers working on Linux is the problem.
I read that it is possible to run OSX on non-Apple PCs, but that doesn't seem 
to be as easy.
Also not something that could be done officially, e.g. running OSX as a VM on 
a continuous integration server.

Do you know if the Mac packaging group is just building the software or if 
they also run the automated tests?

> >>>> 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 … :-(

Sure, but my main point was that the bug reported reached the correct target 
audience, the people who prepare the packages and who have the domain know-how 
regarding building on that platform.

Especially things like version dependencies need to be analyized, fixed and 
tested by platform experts.

> >> 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.

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, so either fixes are not developed 
at all or are lost between KDE releases.

That indeed doesn't sound sustainable, but I don't see any way to address 
this.

> 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.
And some of the dependencies look "wrong", e.g. the X11 ones.

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 :)

> >>>> 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.

Well, yes. The main testing is done by the developers, through manual testing 
during development and automated testing, etc.

But here we are talking about platform/integration testing and that has to be 
done by people on said platform.

It is just that the OSX platform seems to be so different in how the community 
around it is structured. On other platforms part of the packaging community 
are developers, they have tester groups with access to beta releases, etc.

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.
Such a target audience does sound like a great market for service providers 
though who could provide the testing and packaging as added value over what 
the upstream communities can do.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]