In reply to <a href="https://pointieststick.com/2026/06/22/network-shares-still-talking-about-them-in-2026/comment-page-1/#comment-41002">Thomas</a>. Possibly! No promises though...
<!-- wp:paragraph --> <p>Is there any chance drag&drop from SMB shares opened in Dolphin to a different application will end-up working as part of this work?</p> <!-- /wp:paragraph -->...
<!-- wp:paragraph --> <p>I'll never understand why GNOME in specific seems to attract the type of person that deliberately acts in an inflammatory way, then tries to act like the victim when the inevitable, obvious consequences of their actions come to bite them. We have a name for this - crybullying. Hari is not the first and will not be the last in a long, infamous line of GNOME contributors that act this way. It's a deep rot within that project, even affecting its Foundation as recent other drama has shown. It's an elephant in the room they seem to have no interest in addressing. I just don't get it.</p> <!-- /wp:paragraph -->...
In reply to <a href="https://pointieststick.com/2026/07/21/legal-obligations-vs-social-contracts/comment-page-1/#comment-40998">tngaskell</a>. Indeed it is not common for discrete-release distros to do things like change the bug report URLs of the old software they package, or changing branding if they heavily patch it. And that's something that should change IMO. I think there's an element of "if we want distros to do this, we have to make it easy for them". And that's where I think it helps to start with a conversation rather than going in with demands and requirements...
<!-- 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 -->...
In reply to <a href="https://pointieststick.com/2026/07/19/whos-responsible-for-bug-reports-on-old-software-versions/comment-page-1/#comment-40993">Sebin</a>. I don't think that Hari (TheEvilSkeleton) was looking for a fight, and I didn't write that, or even imply it. I only objected to their tone and approach. The actual content of their complaint is something I almost entirely agree with. And I think with a more diplomatic approach, it might have been possible to avoid the conflict and get something useful done. Instead, it turned into a fight that Hari appears to have lost, since I don't see Linux Mint making the requested change. Yes, this is tone policing. That's because I think tone is important! Not caring about it provokes avoidable fights and causes everyone to dig in their heels...