But also this should mean that the buck stops with the distribution, not with the developers.
Then make absolutely sure your users all realise this, and that they should come to you for support not the devs (unless they themselves are devs, have read the relevant documentation, all of it, and able to offer useful help with the matter).
> But also this should mean that the buck stops with the distribution, not with the developers.
The clarifying points further down the article, that is the thrust. The basic rule for releasing WiP code being “don’t” and the advanced rule being “don’t, unless you really know what you are doing and can support it yourself”.
Here's one example where I've done it: https://github.com/NixOS/nixpkgs/blob/350fd0044447ae8712392c... since new rust has already been merged and rbspy still has no release with the required patch, there are two options: a broken package or an unreleased patch.
It's a cost/benefit calculation for the maintainers.
I think the issue isn't an individual patch that hasn't been completed, such patches are unlikely to be checked-in anywhere.
It is patches that are part of unfinished work, or that have not been integration tested with the rest of the product, or are not stable/useful/safe without other work that has not yet been merged. Basically patches intended fr other project devs, not the general userbase yet.
But to answer the question directly, in case it is literally unfinished patches:
> What is the use case for shipping unfinished patches?
“Being the latest & greatest” willy waving in end-user aimed distributions.
I can see a use case for some dev communities, though mainly for proactive compatibility testing purposes, not for dev or non-test deployment environments.
