What KDE would like distributions to do

[Luca Beltrame]

In data domenica 20 marzo 2016 21:46:43 CET, Thomas Pfeiffer ha scritto:

Hey Thomas,

> we have now collected what we think distributions can do to make our
> software shine, and here is what we were able to come up with:

This is mine, and openSUSE's KDE team view on it.

> -  No downstream patching, if possible
> 	- If it's strictly necessary, we'd very much appreciate it if it was
> together with a bug report on https://bugs.kde.org - If you can develop a

This assumes that patching is done to "fix" KDE software somehow. While this is 
true in some regards, it needs clarification. At least in openSUSE, we have two 
kinds of patches that *may* be applied to our packages:

- Upstream patches: these are backports of fixes that have been already 
submitted upstream but not part of an official release yet, or for a newer 
version that hasn't been backported yet (see below on why). Examples include 
the Qt patch for the infamous kded5 deadlock with Qt 5.6.

- openSUSE specific patches: these are mostly "integration" patches, like 
providing compiler flags, correct library locations, and/or stuff that allows 
the software to coexist in the distribution(s) as a whole. I used the plural 
because we support multiple distributions out of a single package definition 
(yes, formally incorrect, but you get the point ;)

We've been trying to keep the latter patches to a minimum, also because they 
have a maintenance cost.

> fix for a problem yourself, that's great, but please offer it upstream

At least in our case, we do it already: all the major packagers in openSUSE 
have KDE contributor accounts and have been submitting fixes upstream since a 
while. And if not submitting fixes, at least pestering developers if things 
break (hello Plasma people, do you remember me with multiscreen issues? ;) so 
that changes end up upstream.

> Respect release cycles. If you are able to synchronize your release
> schedule with ours, that would be ideal - Most optional dependencies are

In openSUSE's case, it depends on which angle you look at it:

- Tumbleweed has generally no problem, because newer versions are submitted as 
they're available. It may take a bit to arrive to users (see below on 
"testing" to understand why) but this is done in a timely manner.

- Leap has 1 year release cycle and it's marked as a "stable" release, 
therefore it should stay a little more static software-wise (tried-and-
tested). That said, we *may* (and we already did) provide updated versions of 
the KDE sofware stack via the so-called maintenance updates. IOW, it's 
possible, but it's at our discretion.

> because of non-linux platforms
> 	- We expect Linux distributions to fulfill them

Then new dependencies should be communicated in advance, or when the tarballs 
are made ready for a new (beta) release. Sometimes it's guesswork, or checking 
the CMake output, which is not ideal with automated build systems.

> - Recompile plasma-integration/frameworks-integration on every Qt update
> (and any other software using private Qt API)

This is already done or I wouldn't have my CJK input working. ;)

> Testing
> - Please Test stuff systematically, not just a quick unstructured "Let's use
> the new release ourselves for a while and see if it breaks" kind of test -

That's the best part in openSUSE, we have this covered. ;) openQA does a range 
of "normal" desktop tests, from login to launching a number of applications, 
and compares the result with previously stored "good" conditions. It's been an 
excellent resource to bring  software into openSUSE.

In the case of Tumbleweed, openQA is also run before publishing a new 
snapshot: so, in case something breaks (openQA tests a lot of things, not only 
KDE software), the snapshot publishing is delayed, hence sometimes it may take 
a while for updates to reach users. ("A while" is in worst-cases usually a 
week).

One topic that I would like to mention is that the changes in artwork in 
Plasma have been large for every release, and this breaks the testing because 
of course, looks change. So perhaps visual changes like theming should be 
properly communicated.

In addition to automated testing, most of the KDE team runs the latest Plasma, 
Frameworks, and Applications code from master. This helped us finding and fixing 
issues before they reach users.

> Look and Feel
> visuals. Please use them if possible. - If you want to create your own
> themes, we'd encourage you to discuss your changes with the VDG to ensure

At least for openSUSE, you have to bear in mind that we are shipping 
*multiple* desktops, and they should have at least a coherent branding. 
Therefore we can't give KDE software a preferential treatment. 

Nevertheless, for a number of reasons, we're using upstream branding in Plasma 
at the moment.

> If visual changes are provided, store them into a Look and Feel package so
> the user is able to easily switch from the distro default one to the
> upstream default one (Breeze) and vice versa

That's what we used to do.

> - Graphics drivers are very important for a comfortable Plasma experience.
> Make sure they're correctly set up.

openSUSE Tumbleweed has the latest X11/Mesa available when released. 
Unfortunately that doesn't mean there aren't driver regressions (hello, Intel 
driver!).

> System Settings
> - Do not ship your own KCMs if they mostly duplicate or replace existing

While not a "KCM" per se, the openSUSE way to configure the distro is YaST, 
which has an entry in System Settings. Since YaST is used to configure things 
in a distro-neutral way, it's going to stay there. And while it can certainly 
duplicate some functions (the fonts module, for example), we think it's a 
small price to pay.

> KWallet
> - Configure your display manager to be able to unlock the default wallet via
> PAM (see

This should be aleady done.

> Discover
> - Make sure Appstream information is properly pupulated in your
> distribution. - Make sure PackageKit is properly set up. It's possible to

We actually provide AppStream information in our packages, and the integration 
is there. However, there are differences between the "regular" AppStream 
specification and what GNOME uses (and we also ship GNOME), so things are 
sometimes more complicated than what it seems at first.

> have a different backend, besides PackageKit, but it's not the recommended
> solution, for maintainability.

We have a PackageKit backend for libzypp, which is the solution to handle 
package management in openSUSE, and we use plasma-pk-updates (software 
maintained in KDE git) to provide updates to users.

-- 
Luca Beltrame - KDE Forums team
KDE Science supporter
GPG key ID: A29D259B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/distributions/attachments/20160321/13d89a7e/attachment.sig>