| 11 Sep 2021 |
 jonringer | If that's the case, the fix should have been merged into staging next or master | 19:08:45 |
 asbachb | The problem is that it needed a fix that was just available in staging. | 19:09:15 |
| asbachb | But the PR needed quite some time for merging so the fix for the lib is now on staging-next and the bottles fixed is in staging. | 19:09:53 |
| jonringer | Then it will have to target staging. The staging next paradigm is to limit stressing the infrastructure beyond what it can handle | 19:11:21 |
 lukegb (he/him) | This staging-next cycle's been open for a while, but I'm hoping it'll settle down relatively soon so we can get started on the next one | 19:11:52 |
 sterni | asbachb: you can also just PR the change into master once staging-next is merged | 19:38:11 |
| asbachb | sterni: from staging-next to master or via a new PR? | 20:37:53 |
| sterni | if it's already merged into staging, I'd just wait, less hassle | 20:40:59 |
| asbachb | It's a little bit annoying as building myself takes several hours due to the dependencies. | 20:41:27 |
| sterni | sure, but the staging(-next) workflow ensures that staging (and to an extent) staging-next are the only branches where this happens | 20:42:49 |
 trofi | what is the rough criteria to merge staging-next into master? zero build failures on both? or when staging-next is stirctly better? | 21:09:42 |
| asbachb | I wonder if it makes sense to provide the binaries for staging next somehow. Maybe this would also encourage more people to help fixing. | 21:14:42 |
| asbachb | But testing a fix maybe waiting several hour for the dependencies to build it quite annoying. | 21:14:57 |
