Next Plasma LTS and openSUSE

[Luca Beltrame]

In data martedì 18 aprile 2017 16:37:18 CEST, Aleix Pol ha scritto:

Hello Aleix,

sorry for the delay in the response.

> Clearly having an LTS release doesn't cut it for openSUSE, as we
> already did that last time and for the next release we're receiving
> yet another e-mail like the house is on fire.

openSUSE is in part handled by SUSE (the company) and in part by the 
community. There are cases where the the wishes of the individuals in each of 
the two may differ a lot. That is why some individuals (including high-profile 
community members) are pushing to use GNOME by default, which is the desktop 
used by SUSE Enterprise Linux. The main reasons, as far as I can understand, 
are the fact that there are people working on it already, and because they 
would share the development/maintenance with RH. And RH handles a good part of 
GNOME, so it's clearly seen as "enterprise".

Of course, openSUSE *doesn't* have to do that by default, and in fact that is 
why (long) threads have went on the relevant topic (although the community is 
sadly very keen on converting all discussions and debates into
awful flamewars, with no actual content except "KDE sux" and "GNOME sux more"). 
As far as I can understand, this topic comes out every now and then 
internally.But at least IMO, what we want to do is to make Plasma even more 
viable than before (it is already a lot, in my unscientific opinion) to ensure 
it is not demoted for mere politics. 

> - Which parts from 5.8 have worked well?

The whole LTS part in my opinion worked *remarkably* well. It provided a very 
good desktop, supported by bugfixes over long periods of time. I would add that 
also the beta and the early release phase done almost impeccably. Timing was, 
as discussed at the time, very useful. 

> - Which parts from 5.8 haven't worked well?

Some are due to the process, and not a fault of Plasma itself. The openSUSE 
maintenance team, which is in charge of the stable version updates, doesn't 
like when we supply tarballs with updated version numbers and no actual 
changes. On the other side of the fence, I know this may cause some logistic 
problems (I know that David Faure rejected such an approach when some Kolab 
Systems people asked for it in KF5). 
In some cases, commits broke building and the (very rare) "feature" changes 
like when the tm partial rewrite code ended up in 5.8. In general terms, there 
were a more than a few case of regressions.

> - Do you have the feeling that your feedback is acted on?

In my opinion yes, but I have one foot in two shoes, so to speak. ;)

> - Where are the problems we should be concerned with?

Detailing arguments why some favor GNOME over KDE would just result in 
bikeshedding, but we can list some if you'd like to.

> Personally, with my Discover hat on, I have seen very little feedback
> from opensuse and that worries me:

We don't have Discover installed by default. Some of the reasons are:

- We found PackageKit to be not too reliable (in our experience).
- The zypp based PackageKit backend used by openSUSE does not stay active in 
the background, which is a problem for Discover (but also for other AppStream 
software centers). A fix is being worked on.
- Other KDE team members found Discover to be very prone to crashes, but it 
may have to do with Qt rather than Discover itself.
- We found the UI to be a little alien to the rest of Plasma.

It's installed by default on the KDE live images (not the general openSUSE 
lives, but KDE team live images) though.

With all that said, let's also focus on the future: Qt 5.9 will be a LTS 
release (and will be likely also shipped by "enterprise" distributions), so it 
would be a good idea to plan a new Plasma LTS release sitting on top 
of Qt 5.9. What do you think?

Thanks in advance.

-- 
Luca Beltrame - KDE Forums team
GPG key ID: A29D259B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20170513/581b8503/attachment.sig>