[KDE/Mac] Hi (from Kolab Client "Team", part of)

[Mike McQuaid]

On 23 Aug 2010, at 14:57, Bernhard Reiter wrote:

> Hi Mike,
> 
> Am Donnerstag, 19. August 2010 15:02:28 schrieb Mike McQuaid:
>> It's cool that there is a commercial effort ongoing on this front and I'd
>> like to help here if I can.
> 
> good to read you here! 
> (Just so that our other readers know: Mike works for KDAB now. KDAB is a 
> partner company to Intevation. In my last email I was mentioning a contract 
> Intevation+KDAB+g10code were working on in 2008 and 2009, that had a small 
> KDE on Mac OS component.)

It's worth mentioning that I've never worked on KDE on Mac stuff as a KDAB employee and may never do so. Anything I say on this list is with my KDE hat on, not my KDAB one :)

> I guess I have to clarify the "commercial effort" aspect some more:
> We are professionals and in 2008 and 2009 we had a paid project to advance KDE 
> on Mac a few steps, which we did. Currently we have no contract to do so
> and no working business model. There are a few people inside our companies
> who would like to run Kontact on Mac and they might put in a bit of their 
> time. There is a small business interest for all three companies and Kolab 
> System  to have a full blown Kolab Client on Mac OS and thus possibly a small 
> time investment into a future working business model. However this would mean
> we are getting or having the prospect of getting paying customers or a 
> customer that finances stabilizing Kontact and its packaging on KDE.

Cool.

>> Did you manage to read the packaging discussion thread (titled "Developing
>> KDE on Mac")? 
> 
> I've seen, but not fully digested it yet. I'll hope I'll get to it soon,
> feel free to ping me again if that takes too long.

No rush, it was just related to what you mentioned.

>> I raised some concerns there that I'd like to raise with you: 
>> 
>> - There's a few people doing work on this but we're all taking different
>> approaches and not discussing it on the mailing list. Specifically, you and
>> Sjors seem to have the same approach but one of you is using Macports and
>> the other Fink.
> 
> I agree we should select a sync point. I'd say we use the mailinglist until we 
> have something better. This is why I've send my post here.
> (From aboe it should be clear that I cannot promise that much work is done.)

Cool, agreed.

>> - There are too many patches in Macports/Fink that really should be
>> upstream in trunk and the release branches.
> 
> Without know the details or the affected patch numbers:
> Naturally the best place for a patch should be sought and this is has high
> as possible. Packaging changes could be kept in a place
> close to the packaging as well. My experience from other initiatives also 
> let me believe that if we want to get a product released that can be 
> stabilized, we often need the ability to put in further patches because
> that usually takes less time.
> And getting something out is very important to grow the community.

Cool. I guess I just mean the patches that are specifically listed in the Macports/Fink build files and can be easily obtained from there. For example:
http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/Portfile
and
http://trac.macports.org/browser/trunk/dports/kde/kdelibs4/files


>> - As a result of the patching, KDE on Mac basically doesn't work without
>> using these patches. This seems a bad situation to me and I think that the
>> port has stagnated somewhat due to this.
> 
> Putting patches upstream includes them into upstream maintenance, so it is a 
> good thing. But this is not magic. IMO we should set up nightly builds
> or Kontact Tag builds to let the other KDE developers know when they break 
> something on Mac.

Yes, that would be great.

>> - Most non-technical OSX users expect a .app bundle distributed in a .dmg
>> and using Sparkle for updates. CPack provides the capability for fixing up
>> the dependencies in a .app bundle and creating a DMG.
> 
> During the contract we found out that our effort is not large enough to fully 
> solve the binary, source and update distribution mechanism of a full blown
> product on Mac OS X. So we wanted to join the initiative that is closest
> about solving this, including the dependency management for Free Software 
> on Mac OS X. MacPort seemed to be the best solution at that time according to 
> an analysis by Emanuel. This could have changed over the last 9 months or so.

I don't disagree that it's the easiest, just perhaps not the best for end users (or whoever installs it).

Thanks for the reply :)

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