In reply to @kidanger:kidanger.net
done, https://github.com/NixOS/nixpkgs/pull/311922

In reply to @imincik:matrix.org
Ah, great. Can I add it to nixpkgs ?

In reply to @sikmir:matrix.org
Here it is https://github.com/NixOS/nixpkgs/pull/312708, welcome to review)

In reply to @imincik:matrix.org
Trivial to review QGIS version bump - https://github.com/NixOS/nixpkgs/pull/313097

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)?

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?

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.