What do you mean in pt 1? I've not experienced any issues there, but curious to hear from others.
Nix flow: your patch is not done according to our guidelines, so fuck off. Still not. Still not. Read the guidelines. Still not, read the guidelines. You have to squash commits manually, we won't enable autosquashing because someone important doesn't like them. Nope, your time isn't valuable because there are too many of you and just one nix.
It's like they enjoy spending time to tell occasional contributors, who can't memorize all nix rituals, "fuck off" instead of spending that time to do the necessary finishing touches.
So, critical issues/vulnerabilities remain unpatched, some formulas are outdated by 5 years, because the relevant maintainer says the old package works for him but new one breaks something on his machine and offers to investigate his issue on your own by a single log line. Of course completely ignoring all _your_ issues which are fixed in an upstream patch made one year ago.
I know people who decided not to make a single contribution to nixpkgs until the things change because of that shitshow and I joined that movement. It's really easier to have a personal private fork of nixpkgs and make all the changes there instead of dealing with the upstream and that's what I would strongly recommend to any nix newcomer.
> maintainer says the old package works for him
We’re all just volunteers, who are doing this in our free time. Usually this works well enough for most packages, but you are always free to submit the fix yourself on nixpkgs ;). At least compared to other distros, that workflow simpler.
Probably you are lucky.
> always free to submit
I did. The problem is that in this particular case there is one guy with merge rights who doesn't want to update a package because it breaks something for him so the package is outdated by years. He provided me an excerpt from his logs and said that the update doesn't work for him. Period. They don't even think that the outdated package doesn't work on _modern_ hardware.
This ... seems entirely reasonable, though?
As you point out, having to do extra work on behalf of others isn't desirable.
-- If a pull request is made and the maintainer(s) don't like it, the options are "reject it", "maintainer puts in extra work to accept it", "pull request author puts in extra work to get it accepted".
With as many open PRs to nixpkgs as there are, it seems reasonable to ask that pull requests are as streamlined as possible.
That this isn't a great experience for new (or infrequent) contributors is unfortunate; although, "contributing" was raised as a pain point in the last community survey. https://discourse.nixos.org/t/2022-nix-survey-results/18983
Yeah. It's better to spend more time repeating "read the guidelines" instead of fixing the commit message. And of course it's better to keep critically vulnerable packages (netatalk, potential remote code execution) for months and piss off the maintainer (not me) instead of turning on the autosquash.
For security issues, mentioning cve gives the pr a security tag which helps speed thing up.
I agree that if the maintainers are compensated for their time, patches would be a lot more efficient in these scenarios to clean up the loose ends.
My favorite was when the GNOME ISOs got so bloated it no longer fit on a DVD size-wise and nothing could move to unstable for over a week while folks hem and hawed about what to do with that situation. Not saying a little bikeshedding + solution digging isn't good for the long-term, but it seemed so odd that this was preventing anything from going to unstable. (https://github.com/NixOS/nixpkgs/issues/159612)