3 ms·

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

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.

pshirshov 4y ago
That's exactly what I'm talking about and I don't see any point in making any contributions there. I just feel better maintaining my own private fork.
- toastal 4y ago
  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 https://github.com/NixOS/nixpkgs/issues/159612)
viraptor 4y ago
The pr naming is strict, because a lot of the ci and automatic processing depends on correctly named commits. And you do want them to run well.
- hamandcheese 4y ago
  Seems like the naming should be its own CI check (or a comment bot or something) rather than result in rejection by a human.

pshirshov 4y ago

That's exactly what I'm talking about and I don't see any point in making any contributions there. I just feel better maintaining my own private fork.

toastal 4y ago
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 https://github.com/NixOS/nixpkgs/issues/159612)

viraptor 4y ago

The pr naming is strict, because a lot of the ci and automatic processing depends on correctly named commits. And you do want them to run well.

hamandcheese 4y ago
Seems like the naming should be its own CI check (or a comment bot or something) rather than result in rejection by a human.