Hi guys, just wondering what you consider an appropriate level of PR review for bot-generated patch releases like libgeotiff: 1.7.1 -> 1.7.2. Some things to consider:

• Anybody doing a review has finite time, and want to do the best possible job in that finite time.
• Somewhere between 11 and 100 packages rely on this one, as detected by ofborg. So the impact of a broken package isn't tiny.
• The package passthru tests are run automatically, but it's hard to gauge at a glance whether those are as complete as they should be, because it's not like we report some kind of coverage front and centre.
• I don't think NixOS tests are typically linked to the package passthru tests, so it's non-trivial to figure out whether any NixOS tests should be run for a particular PR. Do you have any tricks/heuristics for figuring out which tests to run, better than rg libgeotiff nixos/tests (which won't detect tests of packages which depend on libgeotiff)?
• If a rubber stamp of "the build passes" is considered sufficient, why don't we automate the merging of such PRs? Then people could spend their time reviewing actually interesting PRs, and we might get more ROI on review time.

In reply to @vengmark2:matrix.org

Hi guys, just wondering what you consider an appropriate level of PR review for bot-generated patch releases like libgeotiff: 1.7.1 -> 1.7.2. Some things to consider:

• Anybody doing a review has finite time, and want to do the best possible job in that finite time.
• Somewhere between 11 and 100 packages rely on this one, as detected by ofborg. So the impact of a broken package isn't tiny.
• The package passthru tests are run automatically, but it's hard to gauge at a glance whether those are as complete as they should be, because it's not like we report some kind of coverage front and centre.
• I don't think NixOS tests are typically linked to the package passthru tests, so it's non-trivial to figure out whether any NixOS tests should be run for a particular PR. Do you have any tricks/heuristics for figuring out which tests to run, better than rg libgeotiff nixos/tests (which won't detect tests of packages which depend on libgeotiff)?
• If a rubber stamp of "the build passes" is considered sufficient, why don't we automate the merging of such PRs? Then people could spend their time reviewing actually interesting PRs, and we might get more ROI on review time.

In reply to @imincik:matrix.org
I do a visual diff review, check if all tests are passing and run nixpkgs-review (this sometimes requires a lot of resources)

In reply to @vengmark2:matrix.org
That last one is a big one, but one which could (and I expect will, in the future) be run by CI. I think we can safely assume that nixpkgs-review is beyond the effort that most would be willing to donate, since as you say it requires a lot of resources.

In reply to @imincik:matrix.org
Other problem with nixpkgs-review is that usually you are able to run it only on single platform. @sikmir is doing linux + darwin sometimes which is great, but quite rare.

In reply to @imincik:matrix.org
sikmir: are you able to test the build of owslib on Darwin for this PR https://github.com/NixOS/nixpkgs/pull/314546 ? Thanks

In reply to @sikmir:matrix.org
Build on darwin is ok for me (163 passed, 70 deselected, 9 warnings).

In reply to @imincik:matrix.org
sikmir: are you able to test the build of owslib on Darwin for this PR https://github.com/NixOS/nixpkgs/pull/314546 ? Thanks

In reply to @das-g:matrix.org
nix run nixpkgs#nixpkgs-review -- pr 315042 keeps getting OOM-killed after a while (more often than not taking my whole GNOME session down with it). Is there a way to find out which of the builds takes up so much memory, so that I can tell nixpkgs-review to skip it?

In reply to @imincik:matrix.org
Another ZHF PR, easy to review: https://github.com/NixOS/nixpkgs/pull/314801

In reply to @das-g:matrix.org
This should probably be backported to 24.05. Shall I add the labels backport release-24.05 and/or backport staging-24.05?

In reply to @das-g:matrix.org
Backport to staging-24.05: https://github.com/NixOS/nixpkgs/pull/316915
Backport to release-24.05: https://github.com/NixOS/nixpkgs/pull/316916

In reply to @das-g:matrix.org
Backport to staging-24.05: https://github.com/NixOS/nixpkgs/pull/316915
Backport to release-24.05: https://github.com/NixOS/nixpkgs/pull/316916

In reply to @imincik:matrix.org
Should be back ported to release-24.05

In reply to @das-g:matrix.org
I've seen it done this way during ZHF for stuff that blocks other builds on both branches. Is it to be handled differently after release? Oder was that the wrong thing to do already during ZHF?