<!-- wp:quote --> <blockquote class="wp-block-quote"><!-- wp:paragraph --> <p>If you distribute software that you know is or soon will be outside of its developers’ support window, change the bug report URL to your own</p> <!-- /wp:paragraph --></blockquote> <!-- /wp:quote --> <!-- wp:paragraph --> <p>This sounds like it would be a common thing, but it appears to be a departure from how the entire Debian community -- which is as mainstream as mainstream can be in FOSS spaces -- has functioned for the last several decades.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>For example, if I install gnome-calendar (which is the package that triggered your previous post) or gnome-maps or gnome-recipes and probably many others on Debian Stable or equivalent, I get versions from out-of-support GNOME 48 with <em>About -> Report an Issue </em>links that still point to upstream issue trackers despite the fact that GNOME only supports releases for 12 months while Debian only does releases every 2-3 years.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>I assume the Debian packagers would have been willing to change this if Hari had complained to them rather than to a downstream of a downsteram, but searching for soon-to-be-outdated links doesn't appear to be something Debian maintainers are doing by default.</p> <!-- /wp:paragraph -->...
In reply to <a href="https://pointieststick.com/2026/07/19/whos-responsible-for-bug-reports-on-old-software-versions/comment-page-1/#comment-40987">Martin Owens</a>. <!-- wp:paragraph --> <p>Related to that is that a decent chunk of people who used "stable" releases in the past (before the days of always-on connectivity via the Internet) did so because the bug list was known, not because a stable release had fewer bugs. You only reported bugs against stable releases if you absolutely needed a fix (e.g. a critical security issue), not if it was "merely" misbehaving. For misbehaviour, you'd either ignore it and hope someone else reported it, or you'd test on the latest release and report against that.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Bad behaviour went on the "known bugs" list, and workaround for the bad behaviour were shared company-wide. When you were choosing a version of software to use, you'd look at the known bugs list for the stable versions, and decide whether you could live with the bugs for any given stable version, noting that the older it was, the more likely it was that the only bugs you'd see were the known bugs.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>That's gone for two reasons:</p> <!-- /wp:paragraph --> <!-- wp:list {"ordered":true} --> <ol class="wp-block-list"><!-- wp:list-item --> <li>With the advent of Internet everywhere all the time, many more bugs are security-relevant than before. In the days when I used stable releases, we found maybe 1 or 2 security-relevant bugs a year in the (proprietary) software we used across all the releases we used. Now that we're connected all the time, it's not just the security relevant bugs we find that matter, but also the ones attackers are using, which means many more matter to us.</li> <!-- /wp:list-item --> <!-- wp:list-item --> <li>The social layout has changed; BITD, you were either a developer, worked directly with developers most of the time (and thus understood what developers cared about), or filed bugs via a support contact. Nowadays, the people who previously would have filed their bugs via a support contact are able to contact developers directly, and instead of a support contact dealing with unreasonable expectations, they're exposed directly to developers.</li> <!-- /wp:list-item --></ol> <!-- /wp:list --> <!-- wp:paragraph --> <p>I find myself hoping, FWIW, that the growth of rolling, and near-rolling, distributions is going to find us a new equilibrium, where people who take stable releases are back in the "I need my known bugs list" world, and those who want all bugs fixed switch to rolling or near-rolling distributions.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p></p> <!-- /wp:paragraph -->...
<!-- wp:paragraph --> <p>This is a very comprehensive and thoughtful list of good practices. I wish it can be broadly adopted.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Mint's unwillingness to follow libadwaita updates that bore the question is a valid position, but wasting upstream time by not renaming the apps is questionable. FOSS is an ecosystem and each actor affects the other. Your list translated the abstract rule of "don't unreasonabily burden other people" in more concrete and actionable ones.</p> <!-- /wp:paragraph --> <!-- wp:paragraph --> <p>Thanks.</p> <!-- /wp:paragraph -->...
<!-- wp:paragraph --> <p>This is a love letter to the culture of free and open-source software.</p> <!-- /wp:paragraph -->...