Normal flow in other distros I contributed to: "thanks for the patch, we'll do the rest".
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.
I can say I've had merge requests denied because I used the title "xxx: init @ 1.0.0" instead of "xxx: init at 1.0.0", but when upgrading packages you must use a symbol, either "->" or "→", but initialization doesn't allow a symbol. Nitpicky but fine, I update the commit title and I wait 2 months for approval+merge. There's also a long disconnect between approved vs. merged in general; I currently have 2 or 3 merge requests already approved by community members for over 2 weeks, but no merge. It's very handy to have friends/coworkers that can help you get through a fast approval so the merge wait can begin ASAP, otherwise you'll be lucky to even get that review.
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.
I've had to resort to doing the same a lot of the time as I await the merge process. Even after merge, it may take Hydra 3 days to get your changes from the default branch to even nixos-unstable for general usage. I find a fork a bit easier than piling overlays and forgetting to move on from them.
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)
> Nope, your time isn't valuable because there are too many of you and just one nix.
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.
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.
This may be annoying, but it makes sense at scale. If you learn the rules, you'll do it right the next time. If I fix commits, I'll handle a fraction of the PRs I could otherwise - and submitters will learn that anything goes (And I am still fixing the most trivial issues)
For security issues, mentioning cve gives the pr a security tag which helps speed thing up.
I'm not a full-time nixpkgs developer being paid for that. I'm willing to make occasional contributions but won't if it costs me too much. If it's cheaper to maintain a private fork I would do exactly that.
That's the thing though - almost nobody is. Neither are the people merging the PRs, and while there's significantly fewer committers than contributors, the current setup just makes sense at scale. I'm not saying it's a good end result, just the most efficient at the time.
This couldn’t be any further from my experience. Instead of being told fuck off, I was offered (and later offered when I became a maintainer myself) constructive criticism, often times with the patches, required to make it up to standard, included.
> 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.
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.
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.