Software Quality Assurance (FOSS and non-FOSS) 🛡✓

There is a widespread twisted perception that bug report filers are beneficiaries regarded as parasitic leeches looking for a hand-out; looking to be served. Developers sometimes treat them as such. They approach a bug report as if they are being summoned to do free labor for the bug submitter.

Bug subitters are project contributors, not beneficiaries

This really needs to be straightened out because the shitty attitude causes bugs to persist without proper treatment. Often I am about to report a bug but first search for existing reports and find that the same bug was already reported long ago and rejected or disregarded. Sometimes it’s because a developer or pkg maintainer has an ego or god complex that didn’t get sufficient stroking. Because of a personality conflict between the first people on the scene, everyone else loses.

Bugs are not owned by the submitter

If Bob submits a bug report, that is not “Bob’s” bug. It is a community bug report. The bug is not fixed for Bob. It is fixed to improve the software quality for everyone. In most cases, by the time the fix is in Bob has already moved on. He found a workaround. It is the future users to benefit from avoiding the time waste of the bug encounter.

Users and testers are not necessarily developers. Devs and others sometimes comment to the bug submitter: “when can we expect a patch from you?” WTF? The tester may have gone through a lot of thankless effort to gather logs and details about a bug, possibly going through hoops to register and use a shitty bug tracker, and they get this culturally fucked up slap in the face in return, demanding more labor of them. It’s labor that requires a very different skill than bug reporting. A tester may know some languages but not necessarily the one needed for a fix.

About labor

The Debian project has a very good principle that goes like this: no one is forced or expected to do work. FOSS contributors are self-directed volunteers who rightfully choose what to work on, if anything. That’s for everyone, not just devs. Volunteers are in control of their own triage of priorities and workload.

A bug report declares: here is a bug (and possibly a workaround). The bug report imposes no work on devs or on the submitter. Even if a dev decides not to work on it, the report still serves to inform other users.

It’s fair enough to say “this bug report needs more details”. It’s also fair enough for a tester to decide whether or not they have the time to dig deeper.

The shitshow is largely described here. That’s LaTeX-focused, but the whole FOSS infra is a disaster.

We need an app that can harvest bug reports from multiple sources and build a local database that aggregates all bug reports. That is, it harvests bug reports in github, gnu.org, Salsa, as well as distro-specific reports (e.g. Ubuntu bug reports from launchpad and Debian bug reports from debian.org).

Rationale

• Dupe reports (due to lazy people)-- Some trigger-happy testers/users do not bother to lookup whether a bug is already reported. And most of the rest only check one db, not all.
• Dupe reports (by design)-- The Debian guidance is to report bugs to the Debian bug tracker (to some extent, even if the bug is already reported upstream). If not upstream, it’s the maintainer’s job to mirror it upstream. It’s a good policy but diligent testers who check multiple trackers see some distracting redundancy.
• Query limitations-- searching for bug reports is limited to the GUI search form for each DB, each of which is limited in different ways. Just let me fucking grep.
• Offline users fucked-- Bug DBs are naturally online, so air-gapped/offline users have no access to the bug DB. A local DB that can be sync’d from bug trackers when the user is momentarily online.
• Full searching-- a local copy of all bug tracker datasets enables testers to search all records with a single query.

I just encountered the same confusion as others in the linked thread. The pipx tool has this in the man page:

       --pip-args PIP_ARGS
              Arbitrary pip arguments to pass directly to pip install/upgrade commands

So of course I had a space after --pip-args. It failed because the software does not work as documented. Someone reported this in 2019. The software is still inconsistent with the docs. Yet someone closed the bug report.

Re-opening or requesting re-opening requires licking Microsoft’s boots. I’m done with MS Github logins.

UPDATE: prime example of someone who thinks inconsistent docs are “not a bug” in a crossposted thread.