| 10 Apr 2023 |
 K900 | Well github doesn't exactly have a warning state | 13:31:24 |
| K900 | And I think a big red X is preferable to merging 5000 rebuilds into master directly | 13:32:02 |
 cole-h | I'd also argue that there are valid cases where we'd want to merge a large rebuild to master (say, a massive vulnerability in glibc or openssl that allows RCE or things). | 13:32:15 |
| K900 | I'd expect anyone that actually needs to do this to know this is not fatal | 13:32:24 |
| K900 | Like, you can always ignore the check and merge | 13:32:50 |
| cole-h | Related to my last message is I don't want to cheapen the "big red X" from ofborg. If you get a big red X, that PR should not be merged in its current state, period. | 13:33:03 |
| K900 | That's not really true either though | 13:33:40 |
| K900 | There are also valid situations where you might want to merge something that's still broken but maybe becomes less broken | 13:34:02 |
| K900 | And then there's staging where pretty much every PR is red because ofborg can't catch up | 13:34:26 |
| K900 | (not that it should try to( | 13:34:34 |
| K900 | * (not that it should try to) | 13:34:38 |
| cole-h | Is there a documented number somewhere in nixpkgs that says "builds greater than this amount should target staging"? | 13:38:50 |
| K900 | https://nixos.org/manual/nixpkgs/unstable/#submitting-changes-staging-branch | 13:39:19 |
| cole-h | If so, I'd accept a PR adding a new, failing status check in the case that a PR's rebuilds exceeds that amount on any platform.
Otherwise, I'd want that to be codified somewhere before ofborg starts enforcing it. | 13:39:20 |
| K900 | "Mass rebuilds are commits that cause rebuilds for many packages, like more than 500 (or perhaps, if it’s “light” packages, 1000)." | 13:39:27 |
| K900 | I don't think it's really enforced all that much | 13:40:04 |
 ma27 | however there are exceptions, IIRC critical openssl patches went straight to master in the past for instance. | 13:40:22 |
| K900 | But around 2000 is usually where people start complaining | 13:40:25 |
| K900 | Or at least where I notice people complaining | 13:40:43 |
 tea | btw, kind of unrelated, but saving for later: why doesn't ofborg do nixpkgs-review-pr anymore? | 13:41:18 |
| cole-h | I'm still somewhat hesitant (how many times has this happened in the past and caused an issue? honest question), but I wouldn't block anything in that case. Though "at least 500, or at least 1000" is kinda noodly. | 13:41:24 |
| K900 | It doesn't happen that often | 13:41:45 |
| K900 | But I'd say that's an argument for it, not against | 13:41:58 |
| K900 | As most PRs will never see it | 13:42:06 |
| K900 | Also, the exact number can always be tweaked later if it becomes a problem | 13:42:56 |
| cole-h | In reply to @noob_tea:matrix.org
btw, kind of unrelated, but saving for later: why doesn't ofborg do nixpkgs-review-pr anymore? I'm not sure it ever did...? AFAIK, it only ever built packages based on the commit message in a given PR. | 13:43:02 |
| cole-h | Which is why nixpkgs policy is to name commits attr: description | 13:43:35 |
 7c6f434c | Never did | 13:43:52 |
| 7c6f434c | From time to time there are people who run nixpkgs-review-pr on many PRs | 13:44:17 |
| cole-h | ofborg does check if all changed packages still evaluate, but not build. | 13:44:59 |
