| 23 May 2024 |
sikmir | Here it is https://github.com/NixOS/nixpkgs/pull/314101 | 21:34:15 |
| 24 May 2024 |
Ivan Mincik (imincik) | 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.
I do a visual diff review, check if all tests are passing and run nixpkgs-review (this sometimes requires a lot of resources) | 05:49:30 |
l0b0 | 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. | 05:51:03 |
Ivan Mincik (imincik) | 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) And I also check release notes. | 06:26:45 |
Ivan Mincik (imincik) | 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. Yes, that's true. But some kind of nixpkgs-review rebuild is done by bot as well. It has 120 minutes timeout, but you can still reuse binary cache it populates. | 06:33:41 |
Ivan Mincik (imincik) | Running nixpkgs-review for "libgeotiff: 1.7.1 -> 1.7." now. | 06:34:35 |
Ivan Mincik (imincik) | 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. | 06:38:28 |
sikmir | 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. Yes, I can run builds on x86_64-darwin and x86_64-linux, feel free to ping. | 12:30:41 |
| 25 May 2024 |
Ivan Mincik (imincik) | sikmir: are you able to run nixpkgs-review on Darwin for this PR https://github.com/NixOS/nixpkgs/pull/314546 ? Thanks | 10:37:38 |
Ivan Mincik (imincik) | * sikmir: are you able to try to build owslib on Darwin for this PR https://github.com/NixOS/nixpkgs/pull/314546 ? Thanks | 10:38:45 |
Ivan Mincik (imincik) | * sikmir: are you able to test the build of owslib on Darwin for this PR https://github.com/NixOS/nixpkgs/pull/314546 ? Thanks | 10:39:05 |
sikmir | 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 Build on darwin is ok for me (163 passed, 70 deselected, 9 warnings). | 10:56:24 |
Ivan Mincik (imincik) | In reply to @sikmir:matrix.org Build on darwin is ok for me (163 passed, 70 deselected, 9 warnings). Great thanks. Greetings from ZHF Zurich meetup ! | 11:01:14 |
sikmir | 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 By the way, I think it's great idea to request upstreams to properly mark tests that require network access, so we can easily skip it. | 13:18:48 |
| 26 May 2024 |
Ivan Mincik (imincik) | Another ZHF PR, easy to review: https://github.com/NixOS/nixpkgs/pull/314801 | 09:14:36 |
sikmir | One more adoption https://github.com/NixOS/nixpkgs/pull/314877 | 15:50:06 |
| 30 May 2024 |
Ivan Mincik (imincik) | Easy one to review: https://github.com/NixOS/nixpkgs/pull/315042 | 09:36:03 |
das-g | nix run nixpkgs#nixpkgs-review -- pr 315042 keeps getting OOM-killed after a while (more often than not with my whole GNOME session). 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? | 14:17:38 |
das-g | * 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? | 14:18:06 |
Ivan Mincik (imincik) | 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? You can lower the number of jobs executed in parallel using something like this nixpkgs-review pr --build-args "--max-jobs 2 --cores 8" --post-result 315042 | 20:16:10 |
| 31 May 2024 |
das-g | In reply to @imincik:matrix.org Another ZHF PR, easy to review: https://github.com/NixOS/nixpkgs/pull/314801 This should probably be backported to 24.05. Shall I add the labels backport release-24.05 and/or backport staging-24.05? | 14:42:42 |
| 2 Jun 2024 |
Ivan Mincik (imincik) | 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? Yes, please add the label. Sorry, I forgot to do it. | 19:58:10 |
Ivan Mincik (imincik) | Should be back ported to release-24.05 | 19:59:16 |
| 3 Jun 2024 |
das-g | Backport to staging-24.05: https://github.com/NixOS/nixpkgs/pull/316915 Backport to release-24.05: https://github.com/NixOS/nixpkgs/pull/316916 | 13:54:59 |
Ivan Mincik (imincik) | 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 Why two PRs (one to staging and one to master) | 13:56:39 |
Ivan Mincik (imincik) | 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 * Why two PRs (one to staging and one to master) ? | 13:56:43 |
das-g | 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? | 14:00:15 |
das-g | In reply to @imincik:matrix.org Should be back ported to release-24.05 Ah, I see you mentioned only the release branch here. Shall I close the PR to staging? | 14:01:27 |
Ivan Mincik (imincik) | 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? I am not sure about ZHF, but for now we need only one PR to master. | 14:01:34 |
das-g | master already has the change through https://github.com/NixOS/nixpkgs/pull/314801. But as the release branches were cut off before that, they don't have it yet. | 14:02:41 |