In other package manager there is no guarantee that the libs work together. Stackage test the whole ecosystem. You use Stackage X.Y (not libA X.Y + libB X.Y, etc).
All other ecosystems there are some libs that do not work together well, and usually you find out the hard way.
That seems a bit rude. You get the QA you paid for - zero.
And nevertheless, whenever Windows software doesn't work in Wine, you shouldn't think "Wow, how did you fuck that up?". They never promised it'd work in WSL.
It's a company, not volunteers. They're obviously have some long-term strategy to extract money beyond support (it's an editor). They are doing a lot ok marketing right now (dev-rel).
It's very much okay to have high expectation, even if the product costs zero. The user is the product, and so on.
Code that panics on bad external input (such as the OS) is incredibly sloppy. They already have the Result — they can just bubble it up and present an actual error message (and maybe even ask for diagnostics, etc).
WSL is a pretty niche version of "Linux". I would guess that close to 0% of what makes it to the front page of HN had a QA team that explicitly tested it on WSL.
It's pretty self-evident that Linux support can't be expected to mean Windows support. If something is broken in the Windows simulation of a Linux GUI stack you should be complaining to Microsoft, not to the developers of a program that works fine in a normal environment.
Maybe they didn't do any on Windows, because this is for Linux, not Windows. WSL is still not Linux. They do appear to have Windows build instructions, though[0]?
I've not heard of QA in open-source projects... unless it's something peddled by a big corp (eg. Chrome, Go, VSCode etc.)
You are lucky if there's some automated unit testing, but that's as far as these things go. Programmers don't like, don't know and don't want to know how to QA. Also, they generally look at QA with contempt... so, unless forced to, they won't do it.
