Should we make it easier and encourage bug reports to be send to distributions

[Albert Astals Cid]

El Thursday 04 February 2016, a les 21:38:49, Andre Heinecke va escriure:
> Hi,
> 
> tl;dr; I think KDE should encourage and make it easier for distributions to
> link to their own Bugtracker in KXmlGui's "Report Bug" action.
> 
> Sent this to release-team as I would have sent this to kde-packager and
> release-team is the successor of that list.

Yes and no, kde-packager "duties" were split into this list, kde-distro-
packagers and kde-security-preannounce, otoh not sure which one of the three 
is best for this, just saying for completeness :)

> 
> This mail was inspired a bit by recent discussions about optional
> dependencies and how they should not allow packagers to break functionality
> by leaving them out in a review request. [1]
> There is also a discussion on the kde-community list going on about how to
> better collaborate with distributions. Which imo ended up in "Distributions
> can do bad things with optional and runtime dependencies and KDE Developers
> have to deal with annoyed users" [2]
> 
> As the maintainer of Gpg4win I know the problem in the extreme. Gpg4win has
> tons of users and if they experience a bug (or what they think is a bug)
> they go the user facing Program Kleopatra and click on "Report a Bug". This
> ends up in the KDE Bugtracker and the KDEPIM Group then get's reports about
> how batch jobs for gnupg won't work on Windows Server 2012. (This is an
> extreme example but the majority of bug-reports for Kleopatra are from
> Windows users)
> 
> This is because KXmlGui encourages users to report bugs to bugs.kde.org
> itself. Shouldn't this be configurable 

It is configurable

http://api.kde.org/frameworks-api/frameworks5-apidocs/kcoreaddons/html/
classKAboutData.html#a81a6f83d178ba07ea4c4a1abe3e5c04b

> and shouldn't we encourage
> distributions to do some bug triage themself, e.g. link users to their
> tracker first? 

Do distributions have manpower enough so that useful bugs do actually get to 
the developers?

Personally I think i prefer some extra bugs that are because the distro did 
something wrong than not getting the real crashers because the distro did 
change the bugs to end up in their bug tracker and i see no bug at all 
anymore.

Cheers,
  Albert

> I think we should. Afaik debian has the policy that you
> should report bugs to debian and the debian maintainer can triage the bug
> and say "this is upstream" with a (probably more qualified) upstream
> report. The bug is then fixed when a package with the fix is available in
> debian. Great! (This is not idealistic, I see this working with e.g. GnuPG)
> 
> I think this would help because:
> - Developers would get more qualified bug reports
> - Users would get responses from their Distributions, also telling them
> after a fix when this will affect them, which is probably more interesting
> then "fixed in master".
> - bugs.kde.org gets a bit more manageable (hopefully at least for first time
> reports)
> 
> And while this is work for distribution maintainers I think they have this
> work anyway. In the Status Quo report bugs upstream and others with their
> distribution and a package maintainer has to have a view on open bugs
> anyway.
> 
> I expect most package maintainers would be more comfortable in tracking bugs
> affecting their distribution then generally monitoring _all_ bugs of the
> module they are packaging through bugs.kde.org where there might be bugs
> that only affect development versions they are not packaging.
> 
> This should also help Packagers to see issues. There was just a report in
> the kdepim IRC channel (which triggered this mail) from a user that "Search
> does not work" because he did not have the akonadi_indexing_agent
> installed. While it is an issue for KDEPIM (and the kde bugtracker) that
> this case should be handled more gracefully by informing the user about
> that fact. Until this is the case a distribution should require the
> installation of said agent or face Bug reports about "Search not working".
> 
> Regards,
> Andre
> 
> 1: https://git.reviewboard.kde.org/r/126895/
> 2: https://mail.kde.org/pipermail/kde-community/2016q1/002223.html