Date and time formats

IIRC we talked about this at osc16 as well. IMO we won’t be getting anywhere by arguing who’s right or wrong, I think that idea dropped in pretty well by now, and things seem to be changing in a good direction. (Most of) the bugs Leap 42.1’s KDE had ( poor NVIDIA users… ), have had the necessary attention from the KDE people. KDE 5.8 is going to be an LTS release, Leap 42.2’s release has been moved by two weeks to get this KDE version in, just another example.
In short, I think the awareness that KDE needs the distros/communities as much as vice versa is back, now lets proceed and get the things we want in KDE done.

Well, I certainly agree with your sentiments, here. I keep hoping things will eventually meander back to a more amicable and user-friendly co-operation. A lot of work has been done on plasma5, and that leaves us with hope.

The bad news is, I submitted 4 (four) Leap 42.2 Beta 1 Change Requests this morning . . .
The worse news is, taking Kontact as an example, IMHO Leap 42.2 is heading in the direction of the Leap 42.1 <KDE> misery . . . Despite all the work being done on KDE Plasma 5. ]]

Many thanks for the encouraging and constructive words.

Feel free to take over maintainership of openSUSE’s KDE packages, if you know it all better anyway.

Sorry, but I’m sick of this.

And just to state it again:
it makes no sense to report bugs about the KDE Applications for Beta1. These are just copies of the 42.1 packages that haven’t been adapted to the changes in 42.2.
The plan is to ship with KDE Applications 16.08.x, and we will probably submit those to 42.2 soon.

Qt 5.6 (which is LTS upstream) and Plasma 5.7 are in the beta (with many improvements especially for multi-monitor users), 42.2 will come with Plasma 5.8 though which is LTS upstream as well (but currently not even beta yet).

OK. Keep calm – software testing is not easy – it’s more difficult than writing code.
Yes, we’re not “nice” – and, we do our best to be polite.
[HR][/HR]Please be aware that, most software testers prefer to see Change Requests closed off by the Test Instance (in this case the user community – does not have to be the person who raised the request) which raised the request – in other words, a Change Request is never closed off by the developer who submits the changed code to the build process.

I don’t fully agree with that, especially it’s sometimes (often?) not easy at all to reproduce a reported bug and try to fix it.

I will try to calm down, but it was a hard day, and I actually wanted to spend some time investigating (and hopefully fixing) a real bug I was finally able to reproduce yesterday (dolphin filling up /tmp if you are browsing the trash which I didn’t manage to reproduce so far although it has been reported 6 months ago already), instead of replying to “useless” (no offense meant) bug reports.
At least I filed that upstream too for now, with exact details how to reproduce.

Well, actually I am quite calm again already… :wink:

Yes, we’re not “nice” – and, we do our best to be polite.

I don’t see how comments like “42.1 was a disaster”, and “42.2 is heading to the 42.1 <KDE> misery as well”, or “In other words, with respect to KDE Applications, Leap 42.2 will be a repeat of Leap 42.1 . . . (Very embarrassing for both openSUSE and KDE . . . )” are very polite to people who spend hours per week (and sometimes even per day) in their spare time to deliver this software to you for free though. And not only in openSUSE, but also KDE upstream.

I’m pretty sure I’m not the only one having such feelings (increasingly).
And I can understand upstream developers getting defensive and “arrogant”.
(Some) users do tend to cross the line (sometimes by far) in bug reports or elsewhere (e.g. forums, mailinglists, blogs). I’m not specifically addressing anybody here now with this though.

Please be aware that, most software testers prefer to see Change Requests closed off by the Test Instance (in this case the user community – does not have to be the person who raised the request) which raised the request – in other words, a Change Request is never closed off by the developer who submits the changed code to the build process.

That’s not how open source development works though, in KDE or openSUSE (the community maintained part) at least.

A bug report is normally closed when the developer submits the corresponding fix to the source repos, or if the developer/maintainer decides to close it for other reasons (invalid/wontfix/whatever).
Some users don’t even bother to report back if you ask them whether the fix works or not.

At least in openSUSE (which is a community distribution), everybody has the rights to reopen bugs too if they disagree with the resolution. I haven’t closed yours though anyway (even though I was nearly considering it already because it seemed to just turn into a rant).

PS: please don’t get me wrong.
It is of course good and welcome to point out problems, but such general rants, especially in (but not limited to) bug reports is not helpful at all, and may only discourage people to fix/improve things.

** Flame off **
[HR][/HR]With the KDE Plasma 5 version 16.08.0, the Kontact PIM is looking much better than yesterday’s offering.
Quickly flipping through the other KDE applications in that Plasma version, the world is beginning to look somewhat more peaceful.
Bottom line: we now seem to have a solid and reliable base for some effective Beta testing!!!

Yes … even though I sometimes get edgy with my own comments in frustration.

It is all a lot of work, especially for those who are working on a huge task that does not have across-the-board support by their respective project community and are working on it almost alone with very little help.

One case in point: The issue of different widgets and different wallpaper on different virtual desktops:

Dave Edmundson of UK is working on it, though he has been quite busy with other things, and has actually made a comment about the progress (and about some users making unnecessary opinion comments in the actual bug thread … knock it off, you guys! Save it for forums, if you must comment) he has been making.

Here I quote Dave, just recently from the “bug” I am tracking:

So to give some update (to show I’m not ignoring this)

From me in #61

[QUOTE]That’s currently super tricky as that class is super fragile; it’s all based around QScreen which we want, yet we needed to get a signal that was broken in QScreen so it’s a combo of two different screen managements systems - which get updates are out of sync \o/ We’ve fixed that in Qt , but we’re not getting that till Qt 5.6. Then that class can half in size.

If you’ve done the maths, you’ll realise that got done in Plasma 5.7 (~6 weeks ago). However it exposed some other startup bug, and now some extra complex layer of multiscreen stuff got added on top - so it’s moved forwards, but still not in quite an ideal state.

Though I will re-itterate, please don’t type opinions in a bug tracker. They just make it harder for me to find useful comments.
[/QUOTE]

… and, I would like to remind all that my original post about Date & Time was not so much a Plasma5 bug, but an upstream decision at Qt that the KDE team is not in control of.