Maybe a hint?

Posted Jan 16, 2026 13:43 UTC (Fri) by koflerdavid (subscriber, #176408)
In reply to: Maybe a hint? by Wol
Parent article: Debian discusses removing GTK 2 for forky

If the tool will be needed for longer than about five years (just ballparking that number) then you really need to consider the software lifecycle of your dependencies as well.

to post comments

Maybe a hint?

Posted Jan 16, 2026 14:08 UTC (Fri) by pizza (subscriber, #46) [Link] (2 responses)

> If the tool will be needed for longer than about five years (just ballparking that number) then you really need to consider the software lifecycle of your dependencies as well.

The mistake you (and far too many others) keep making is by treating "some random person wrote some software and released it on the internet" as a binding commitment to perpetually support and maintain said software. Worse yet, do so in accordance with <formal software engineering process>. Even worse yet, do so for free.

Maybe a hint?

Posted Jan 22, 2026 10:31 UTC (Thu) by davidgerard (guest, #100304) [Link] (1 responses)

The case at hand is Red Hat, not a single volunteer FOSS developer.

Maybe a hint?

Posted Jan 22, 2026 11:02 UTC (Thu) by farnz (subscriber, #17727) [Link]

If it's Red Hat, then you should be able to negotiate longer support via your support contract with Red Hat.

Else, Red Hat is just another volunteer FOSS developer. They might be a big one, thanks to the money they make selling support contracts for FOSS, but unless you're paying them to fix things for you, they're a volunteer.

Maybe a hint?

Posted Jan 16, 2026 14:25 UTC (Fri) by pizza (subscriber, #46) [Link]

> you really need to consider the software lifecycle of your dependencies as well.

In the case of GTK2, that was *eighteen years*.

Goes to show you that no matter how the support period for something is, it will never be long enough.

Maybe a hint?

Posted Jan 23, 2026 19:32 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

The design lifespan and actual lifespan frequently don't line up very well. As the saying goes, there is nothing more permanent than a temporary solution. The quick and dirty solution turns out to be good enough and is never replaced with the well defined, perfectly executed follow up. We've all seen it happen, so we shouldn't be surprised when it happens again.

I think what this actually shows is that our intuition- or my intuition, at least- about the lifecycle of dependencies is backward. My intuition is that big important projects need to focus on stable dependencies, while quick and dirty ones can use whatever is handy. In reality, big, well-maintained projects can afford to use less stable dependencies because they have the resources to deal with things changing under them. It's the quick and dirty projects that need to be built on the most stable base, because they're going to have to keep working without assistance.