Hi Ian and everyone else, On 1 December 2015 at 10:40, Ian Wadham <iandw...@gmail.com> wrote: > Now let me tell you this. > > I am not going to stand any of this "official policy" rubbish. Who do you > think > you are? You are writing from a position of ignorance when it comes to > implementing KDE software on Apple OS X, as indeed are most of the KDE > core developers I have encountered in the last year or two.
I may be speaking from a position of ignorance as to what's possible on the platform and what users of the platform want, but I'm not speaking from a position of ignorance when I state what the priorities of the current crop of KDE developers are. KDE's tier one platforms are currently Linux/BSD/any UNIX where you can run the full Plasma experience with shared packages, etc. In fact, we even run in degraded mode on non-Linux platforms because Systemd and Udev aren't available on such platforms, which are two technologies we make good use of. The developers' priority is to always deliver the best possible experience on these tier 1 platforms. If that comes at the expense of degraded experiences on tier 2 platforms, so be it. We won't be left unable to implement cool feature X on Linux just because to support cool feature Y on OSX or Windows the software has to be architected in such a way that implementing cool feature X becomes impossible. > In my experience, the only way to solve the problems with KDE software, > as implemented on Apple OS X, is to institute day-to-day co-operation > between a small number of MacPorts and KDE developers, not "policies", > patches, reviews and endless email threads. That small group should ask > each other questions about their respective systems until there is a good > understanding of how problems are arising and how they can best be solved. > > But don't look to me. I have sought such co-operation many times in the > last year or two, but now I have given up. You must be completely unaware of one of the core tenets of the KDE manifesto: common code ownership. All code in all KDE projects belongs to all of us, and we all have an equal say in what happens to these codebases. On technical decisions, we reserve comment because the maintainer knows best. But on non-technical issues, we decide on matters together as a community. Because as a community, we can think better. More eyeballs, more brains. "Policies, patches, reviews and endless email threads", as you put it, is how we've democratized software development. If you want the governance to change to a style where an elite few make decisions behind closed doors, it won't happen in KDE. You may argue that you too are a part of the community, and you too want kick-ass OSX support in our code, etc. etc. But refer to what I've said above - right now, we want the best possible experience in our tier 1 platforms. That's what the majority in the community want. The majority in the community also want the best possible experience in OSX and Windows ports, but not at the expense of quality in our tier 1 platforms. Also, as Luca has said, "policies" in KDE are guidelines and may be broken if seen fit to. They're not enforced, but they're there to guide developers and maintainers. Let me make clear what my position on all of this is: If there are patches that make an application or a framework work well on OSX or Windows, we'd like to welcome it with open arms, as long as it doesn't significantly impact existing Linux/BSD code. But more invasive patches (yes, I'll use that term because of all the words in the English vocabulary, this one describes what I'm trying to convey the best) - ones that touch build system code, session management, system interface APIs etc - should be treated with caution. OSX and Windows are two platforms where you shouldn't install systemwide shared libraries and try to do window management, session management etc, or even install your custom crash handler if it needs additional privileges - and if you're trying to send patches that do any of that, maintain them separately outside of upstream please. -- Boudhayan >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
