Bug 1225965

Summary:	Improve KDE Discover bug reporting button
Product:	[openSUSE] openSUSE Tumbleweed	Reporter:	Andreas Stieger <Andreas.Stieger>
Component:	KDE Applications	Assignee:	E-Mail List <opensuse-kde-bugs>
Status:	NEW ---	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	fvogt, shundhammer
Version:	Slowroll
Target Milestone:	---
Hardware:	Other
OS:	Other
See Also:	https://bugzilla.opensuse.org/show_bug.cgi?id=1226117 https://bugzilla.opensuse.org/show_bug.cgi?id=1226397 https://bugzilla.opensuse.org/show_bug.cgi?id=1226395 https://bugzilla.opensuse.org/show_bug.cgi?id=1227192
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Andreas Stieger 2024-06-04 20:02:28 UTC

Whenever we have a generic package issues that affects multiple users like (bug 1225174), we get a whole to of bug reports and duplicates.

All that users seem to be doing is copy the text "<html>Dependency resolution failed:<br/><br/>[...] </html>", report a bug in a random component.

Bonus: If the component is YaST, Huha gets angry like in bug 1225949.

We do not see the bugs that were not reported due to bugzilla pointing out the possible duplicate, but in the example above we got 14 reports. These users may or may not have read through the duplicated bug, or read the recommendation there.

https://github.com/KDE/discover/blob/d644b2a1000c04f084d39a4ef8a3402abf641704/discover/qml/UpdatesPage.qml#L96-L119

Let's improve user experience here. Some ideas:

0. Direct the user to zypper/YaST for self-service resolution of the conflict.
1. Direct the user to a landing page with instructions for #0.
2. Direct the user to bugzilla search first
3. Take the message - extract package names only, strip arch/installed version, sort, and make a hash from it. Use that as the bug alias for automatic reduplication. 
4. or even a fuzzy hash
5. Use a bugzilla whiteboard field with self-service fix instructions

Comment 1 Stefan Hundhammer 2024-06-05 08:19:50 UTC

Dependency problems are almost always NOT problems of YaST, zypper or libzypp, they are problems of the involved packages or of repos that are incomplete or disabled or not present at all. So redirecting such bugs to us would be counterproductive.

If users would simply Google the error message, they would be pointed into the right direction in many cases.

Comment 2 Fabian Vogt 2024-06-05 08:22:51 UTC

The issue is that packagekit doesn't provide any more info than what discover shows there, so we're somewhat limited in what we can do. It also proposes an update first and only on clicking "Update all" it actually errors out. (This is not discover's fault, this is packagekit...).

> 0. Direct the user to zypper/YaST for self-service resolution of the conflict.

Could be done, but earliest for 6.2 if we want translations.

I don't think this would address the issue here though, most users would run zypper dup, see the same error, don't know what to do and file a bug report.

> 1. Direct the user to a landing page with instructions for #0.

IMO the best option, at least for now. Could be a wiki page.

> 2. Direct the user to bugzilla search first

I don't think the search works well with update conflicts.

> 3. Take the message - extract package names only, strip arch/installed version, sort, and make a hash from it. Use that as the bug alias for automatic reduplication. 
> 4. or even a fuzzy hash

That's also complex - the message from packagekit is freetext and translated.
Also needs bugzilla API integration I guess?

> 5. Use a bugzilla whiteboard field with self-service fix instructions

No idea about that.

Comment 3 Fabian Vogt 2024-06-05 08:24:49 UTC

(In reply to Stefan Hundhammer from comment #1)
> Dependency problems are almost always NOT problems of YaST, zypper or
> libzypp, they are problems of the involved packages or of repos that are
> incomplete or disabled or not present at all. So redirecting such bugs to us
> would be counterproductive.

Most of the tuned/tlp bug reports were filed against "Upgrade Problems" which is the correct component for such issues until triaged further. FWICT the default assignee is the screening team, which also fits.