On Monday, February 08, 2016 22:41:08 Sebastian Kügler wrote: > On Monday, February 08, 2016 21:42:58 Alexander Neundorf wrote: > > > I understand that you're saying it doesn't have a place in KDE. > > > > Sebas, you may have missed that I explicitely mentioned eigen in the mail > > you replied to ? > > No, I've missed that. Sorry... > > > I don't understand what's so hard about this: we can say "we consider A, B > > and C to be our core efforts.". That does not mean that everything which > > is outside that "core" must be kept out of KDE. Of course it means that > > software or efforts that support A, B or C, are very welcome. OTOH > > projects > > which don't support the core do not need to be part of KDE, they can as > > well use github or something else. > > > > I think this can only be avoided by not having some technical direction at > > all. > > I think that the technical arguments don't make a lot of sense here, at > least they're not providing the clarity needed: > > - Qt-based, so it should be OK? But why exactly, just because it uses the > same libraries? > - "Supports the core", what is the core? Who makes this call?
that's the 4 items in the draft. It's a draft, a proposal, so they are not set in stone. > Where do you > draw the technical line? (You gave some examples, but most of them feel > quite vague to me, and I'd draw the line at different points. Sure it is vague since the examples were intentionally "interesting" cases. The draft is called "focused": some things are clearly in the focus (just some random examples I could come up with: Scribus, LxQt, libqwt). Other things are, to me clearly far outside the focus: e.g. the eCos RTOS, bash, joomla. The line between "in focus" and "out of focus"/"not supporting the core" is not a sharp line, it's blurry. We can spend weeks on discussing those. > I think one (not the most important) benefit is that drawing the dividing > line by asking "What is your goal?" makes it a lot easier to identify > projects, they can self-select ("Do we identify with these goals?"), and > also be measured internally ("Does this software actually contribute to > *our* goal?") is easier. I think e.g. offering applications which provide a consistent look-and-feel, following the same e.g. HIG, etc. is a worthwhile goal too. We achieve this by using a common set of libraries (Qt and our KDE libraries). We get more done because we gather developers which are familiar with the same technologies: again, the libraries, and in big parts also the programming language. So, the technical aspect is important to me. Alex _______________________________________________ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community