Is anyone else a bit put out over the hoops required to report a bug feedback?

[tempest766]

I understand the necessity to keep the noise down but the requirements to have a bug report addressed give the impression that they don't want bug reports or any possibility of negative feedback. I mean, after all, when you submit a bug report you are in essense saying "your software failed". and as frequently as I find bugs in open source software I'm not inclined to download and build the latest version of every package I find a bug in, just so the "did you check the latest version" requirement is satisfied. There is a reason we use distros in linux, to not have to build packages on an adhoc basis...and most distros are all too ready to tell you to report bugs directly to the project in question.

If I do an issue search for my issue before reporting it, and that issue isn't listed then it probly doesn't matter if the suspect version is off by one or two revision, does it?

[Andarwinux]

For Windows, there are many automated statically linked nightly builds to satisfy the person who doesn't want to build their own mpv. Whereas Linux's so-called GNU philosophy is against providing any prebuilt builds for people and encourages people to build their own, you'd better accept reality.

[N-R-K]

Whereas Linux's so-called GNU philosophy is against providing any prebuilt builds for people and encourages people to build their own, you'd better accept reality.

There's no fundamental reason why there can't be some automated build that builds mpv and packages into a self-contained format like AppImage (I won't get into argument/discussion on whether these formats are good or not). It's just that no one has bothered to do it. But that's a lack of effort issue, not some technical issue like you presented.

[Andarwinux]

There's no fundamental reason why there can't be some automated build that builds mpv and packages into a self-contained format like AppImage (I won't get into argument/discussion on whether these formats are good or not). It's just that no one has bothered to do it. But that's a lack of effort issue, not some technical issue like you presented.

AppImage exists precisely because of the problem I pointed out. The GNU ecosystem is designed to prevent users to try static linking. This basically means that you either have to use musl and give up GPU support, or you have to link everything dynamically and choose a controversial workaround like AppImage. (The static linking I'm talking about is not full statically linked, but statically linked to all normal dependencies, but still dynamically linked to core runtime for interoperability)

Even AppImage may differ with native programs, which may also lead to some problems only in AppImage, which makes it pointless to use it as a standard reference build for issue tracking.

[avih]

I agree it's a problem, especially for LTS distros like Debian, and the latest version at the distro can be quite far behind the current latest mpv version .

However, as volunteer developers, it's also usually a waste of everyone's time to try and analyze or solve an issue which existed at the code a year ago - as is the case with issue which likely triggered this discussion - #17444 , unless we also know that the issue also exists today.

Such users would hopefully be better served by filing the issue at their distro's bug tracker.

That being said, we should make it clearer to users that we can't really help with bug reports about old mpv versions, even if it's the latest version which their distro packages.

The current template does require the user to use a checkbox which says they tried also with the latest, but the distinction between "latest mpv" and "latest mpv in distro" is too easy to overlook or misunderstand.

@tempest766 if you have a suggestion for the issue template - e.g. new wording at the checkbox line or elsewhere at the template, please do share.

Thanks.

[llyyr]

if you're on a distro that doesn't ship the latest mpv release then they're the ones responsible for providing support. report the issue to them, not us

[avih]

if you're on a distro that doesn't ship the latest mpv release then they're the ones responsible for providing support. report the issue to them, not us

But it's on us to make that clear before the user submits the bug report.

[llyyr]

Debian wiki already makes it clear, but sure we can also do that

[avih]

@tempest766 how do you feel about this change at the linux template? would that have made it clearer?

diff --git a/.github/ISSUE_TEMPLATE/2_bug_report_linux.yml b/.github/ISSUE_TEMPLATE/2_bug_report_linux.yml
index b133397cbf..c58b5c0936 100644
--- a/.github/ISSUE_TEMPLATE/2_bug_report_linux.yml
+++ b/.github/ISSUE_TEMPLATE/2_bug_report_linux.yml
@@ -140,7 +140,7 @@ body:
   attributes:
       label: "I carefully read all instruction and confirm that I did the following:"
       options:
-          - label: "I tested with the latest mpv version to validate that the issue is not already fixed."
+          - label: "I tested with the latest mpv version to validate that the issue is not already fixed ([current latest version](https://github.com/mpv-player/mpv/tags) or newer - NOT distro latest)."
             required: true
           - label: "I provided all required information including system and mpv version."
             required: true

[avih]

Note that we're merged a clarification - 92ed2d2, at the issue templates about "latest version", with link to the current latest, and additionally a note about distro version at the linux issue template.