Just dumping a URL counts as a bug report these days?

I hope so, because unless you intend to update your Bugzilla instance to support Markdown like the newer versions do, I can't easily quote the reports filed elsewhere (like in Discourse) should they contain vaguely advanced formatting.

You can view a link. I took time out of my day to file a bug, and I believe that I provided no less than what's necessary to triage it.

However, should some requirement be unfulfilled by me not needlessly reiterating it in a comment here (which I have to update manually in new comments when I update it elsewhere due to also the lack of an edit button) I'd hope that you would inform me in a non sarcastic manner, in which case I'd oblige.

(In reply to roke beedell from comment #2)
> 
> You can view a link. I took time out of my day to file a bug, and I believe
> that I provided no less than what's necessary to triage it.
> 

As maintainers, with this way of thinking, we have to spend time of our day to read this report, then read an external site to find useful information mixed with useless comments from a KDE contributor.

Anyway, the choice to not require the notifier sub-package is intentional, we already have plasma5-pk-notifier which also notifies and doesn't require discover and is consequently far better for this task.

You would get 2 notifications with both notification modules installed.

It all boils down to the choice that we currently install plasma5-pk-updates to notify and install updates, as opposed to discover. In the past, discover has proven to be not reliable and stable enough for the task. Maybe this changed meanwhile?

You can try yourself by installing discover-notifier, replacing plasma5-pk-updates.

> However, should some requirement be unfulfilled by me not needlessly reiterating it in a comment here

The bug report in itself must contain the necessary information to at least understand what its about. Linking to somewhere else doesn't count, because that information is not static (can change or disappear) and might not be (easily) accessible.

The reporter got already informed in the forum what is necessary to file a good bug report. It seems it didn't help.

https://en.opensuse.org/openSUSE:How_to_Write_a_Good_Bugreport
https://bugzilla.opensuse.org/page.cgi?id=bug-writing.html

Created attachment 868510 [details]
Step 1

Created attachment 868511 [details]
Step 2 (result)

Right. I'll ensure in future that I provide a summary, but I expect I can't be expected to update it if it has a duplicate in another, more versatile tracker.

To summarise, plasma-discover currently expects that the aforementioned package be included with any installation of itself due to the fact that there isn't any presence verification code to determine whether the relevant context menu entry is displayed.

Until or unless this is remediated by KDE (https://discuss.kde.org/t/opening-update-kcm-from-discover-shows-blank-page-in-plasma-systemsettings/3149/6?u=rokejulianlockhart) this package should be included.

Since Discover and plasma-pk-updates both use PackageKit as the library that they delegate their heavy lifting to, I would expect them both to be equally as reliable and vulnerable to issues in PackageKit or the PackageKit Zypper plugin (e.g. Bug 1163737 and Bug 1174788). The only real difference would be the reliability and UX presented by their respective the front-ends.

(In reply to Nathaniel Graham from comment #8)
> The only real difference would be
> the reliability and UX presented by their respective the front-ends.

Exactly...

Is there anything *specific* that you have a problem with regarding Discover's system update UX?