[rmccue]

The library I was maintaining (SimplePie) was an RSS feed parser which supported every flavour of the RSS/Atom specs. Because of the history of those particular formats, there were a huge number of compatibility hacks necessary to parse real-world data, and cases where the "spec" (actually just a vague page on a website) was inaccurate compared to actual usage.

This was a while ago (10+ years), but my recollection is that someone presumably had reported that parts of the library didn't conform to the spec, and Debian patched those. This broke parsing actual feeds, and caused weeks of debugging issues that couldn't be replicated. Had they reported upstream in the first instance, I could have investigated, but there was no opportunity to do so.

[dgb23]

That sounds very careless. Not only does this break an obviously deliberate feature, it also violates the robustness principle. Whether one likes it or not, it’s a guiding principle for the web. Most importantly this „fix“ was bad for its users.

Good intentions, but unfortunately bad outcome.

There was a somewhat recent discussion on here on how OS projects on GitHub are pestered by reports as well. Some athors commented that it even took away their motivation to publish code.

It’s always the same mechanism isn’t it. The „why we can’t have nice things“ issue. Making everything at least slightly worse, because there are people who exploit a system or trust based relationship.

[diggan]

Ah, that sounds like a terrible solution from Debian's side, and very unexpected. Sure, patching security/privacy issues kind of makes sense (from a user's POV), but change functionality like that? Makes less sense, especially if they didn't even try to get the changes upstream.

[bityard]

First I want to say that I love Debian. They have a great distro that is simple and quite frankly a joy to use, and manage to keep it all going on basically nothing but volunteer effort.

However, I do believe that in certain areas, they give too much freedom to package maintainers. The bar for being a package maintainer in Debian is relatively low, but once a package _has_ a maintainer--and barring any actual Debian policy violations--that person seems to have the final say in all decisions related to the package. Sometimes those decisions end up being controversial.

Your case is one example. Package maintainers ideally _should_ work with upstream authors, but are not required to because a LOT of upstream authors either cannot be reached, or actively refuse to be bothered by any downstream user. (The source tarball is linked on their home page and that's where their support ends!) I don't know what the solution is here, but there are probably improvements that could and should be made that don't require all upstream authors to subscribe to Debian development mailing lists.

[ak217]

Agreed. The intent is good, but there are recurring problems that arise because of insufficient communication between the distro package maintainers and upstream, insufficient domain experience, or both. I think the solution is to set stronger expectations about what kinds of customizations maintainers should be making (in general, fewer than they make today), how to communicate with upstream, and more code review.

[overfeed]

Users trust Debian (and in turn its maintainers) more than the upstream providers to keep the entire OS stable. Upstream, by definition, are likely to be OS-agnostic, only care about their package and perhaps their preferred dependencies.

Debian has earned that trust, and it's software update rules are battle-tested and well-understood.

[overfeed]

> The bar for being a package maintainer in Debian is relatively low

It's typically an unglamorous, demanding, unpaid, volunteer position a few rungs above volunteering at a soup kitchen or food bank. It's unsurprising that the bar is low.

It's also trivial for upstream maintainers to set up their own competing Debian package repos that entirely ignore Debian rules - Microsoft has one for VS Code.