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

List:       kde-mac
Subject:    Re: [KDE/Mac] Developing KDE on Mac
From:       Mike McQuaid <mike () mikemcquaid ! com>
Date:       2010-08-17 8:08:30
Message-ID: A61E519C-AB59-41F0-BCF4-DE504FEAC120 () mikemcquaid ! com
[Download RAW message or body]


On 13 Aug 2010, at 22:21, John Layt wrote:

> Having read all the thread so far, and last night looked at the MacPorts patches \
> and wondered "Why???" here's my thoughts as a 'core' KDE developer.

> If we claim to support a platform, then the KDE modules should build and run out of \
> the box on that platform, no extra patches required.  For the Mac project to \
> eventually make that claim means _all_ patches need to be in mainline, there should \
> never be patches required by MacPorts or Fink.  People shouldn't have to go looking \
> in other repositories just to get things to build and run, svn.kde.org is the \
> canonical source.  This may mean some parts of KDE are just not built or certain \
> features are disabled until such time as a 'good-enough' solution is coded, but \
> release branch should always build and run.  If a crude hack is required \
> short-term, then so be it so long as we know there's a more correct solution coming \
> and the hack is not actually causing harm.  Patches in Macports/Fink are OK as a \
> short term fix or experiment, but should never be seen as a long-term or permanent \
> solution for anything.

Completely agree.

> This is as much about visibility as anything, if something is ifdef'ed out and \
> marked as not working on Mac, then it is more likely the maintainer (or any other \
> interested party with the ability to do so) will pay attention and help fix the \
> issue.

> Reviewboard now makes submitting patches even easier to do, and really easy to \
> track what has been accepted and merged and what still needs work. I would suggest \
> your first course of action would be to progressively feed all the outstanding \
> patches into mainline.

> As for packaging, I'll leave that to you the platform experts to sort out, but \
> personally I do agree with the general principle that we should at least appear to \
> the user to be using the standard platform installation method they are most \
> familiar with, or failing that the simplest method possible.  The Windows installer \
> is a great tool, but far too complex for the average user.  My other point is \
> telling people to wait 48 hours while MacPorts/Fink compiles all the dependencies \
> is just a no-go, binary installs are the only option.

Agreed here too, as mentioned earlier, doing it the native way takes longer but gives \
a nicer interface to the user.

--
Cheers,
Mike McQuaid
http://mikemcquaid.com

_______________________________________________
kde-mac@kde.org
List Information: https://mail.kde.org/mailman/listinfo/kde-mac
KDE/Mac Information: http://techbase.kde.org/index.php?title=Projects/KDE_on_Mac_OS_X


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