> What if the whole point is about shipping unfinished patches?
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”.
Depends what you mean by unfinished. Does it work and need a style polish? Is the developer trying to debug some tests failing for reasons unrelated to the patch? Is the functionality still missing/broken? There can be lots of reasons why you'd want an unpolished patch rather than wait for a release. Especially with projects that release every few months rather than after each pr.
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.
In the case of manjaro which triggered this post, it's not that manjaro is fixing things. It's manjaro trying their absolute hardest to ship new features faster than the rest, even when those features are completely broken.
Like the fun example of manjaro shipping a merge request of the SMS/chat application on the PinePhone that causes a database upgrade that can't be rolled back. This code was not intended to be merged, even less shipped.
Yeah, it's a balancing act, and it's best when the users and maintainers are on the same page: I don't like maintainers futzing about with packages to fit to arbitrary standards (debian can be quite bad here, and the general policy of 'as close to as vanilla as possible' is something I like about arch), but on the other hand it's much appreciated when packages come with fixes for bad upstream decisions (of which there are many examples), or even important features which upstream has sat on for years (see pulseaudio support for high-quality bluetooth codecs for an example which eventually led to the patch author rage-quitting the project because they strung him along for years). As a user I'm generally happiest when I get the software with the features I want without the bugs which cause me trouble, and it's situation dependent whether the packager or upstream are working against me on that. Usually the biggest source of friction is who actually winds up supporting the result: for all that distros may encourage filing bugs on their own tracker usually users wind up going to upstream for support, even if the issue is caused by the distro's patches. Some badly behaving maintainers (and it sounds like manjaro have been far too aggressive in trying to pull in new features) have I think caused a general pushback from upstream developers as they wind up with a bunch of support requests from someone else's screw-up (see for example home-assistant's attitude to anyone else distributing their software).
If I understand your example, you are using your good judgement as a developer/maintainer to release a workaround that ideally would have been released as a bug fix by the maintainers of the root cause. This is not, however, the issue here, which is the judgement-free release of every work-in-progress as soon as it is made available to anyone, with the bag being foisted on the developers. If that solved your problem, and did so without introducing other problems, that would have been just a matter of luck.
I'm guessing that what you did fits within the article's guidelines so long as you could do it as a tagged release.
I understand the desire to get an early warning of breaking changes coming from elsewhere, but surely scraping together all work-in-progress is likely to raise a lot of false concerns?
> What is the use case for shipping unfinished patches?
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.
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”.