| 20 Sep 2021 |
 Alyssa Ross | nickhu: every so often a version of staging becomes the new staging-next. After that, staging next is worked on for a while to fix any regressions, and let a full Hydra build complete, and then it's merged into master and the cycle begins again. | 17:29:10 |
| Alyssa Ross | So in a few weeks, your gdb update will land in master after going through this process | 17:29:39 |
| Alyssa Ross | Staging is not a place to get extra testing for a package, or to try something out. Its purpose is to group mass rebuilds together. | 17:30:07 |
 Nick Hu | Right, I understand that from the documentation. Let me rephrase my question: is there anything more I should do for this change? | 17:30:18 |
| Alyssa Ross | So the stabilization workflow is largely automatic, except for when build failures are identified | 17:30:31 |
| Alyssa Ross | no, you don't need to do anything else | 17:30:38 |
| Nick Hu | It doesn't really make it clear who is responsible for the stabilization process | 17:30:41 |
| Nick Hu | In reply to @qyliss:fairydust.space
no, you don't need to do anything else Great, thanks! | 17:30:51 |
| Alyssa Ross | everybody and nobody is responsible for it | 17:30:55 |
| Alyssa Ross | Go to https://github.com/NixOS/nixpkgs/compare/master...staging-next and click the button to see the current staging-next PR | 17:31:16 |
| Nick Hu | In reply to @qyliss:fairydust.space
everybody and nobody is responsible for it Just like the old workflow then 😀 | 17:31:37 |
| Alyssa Ross | there, you can see conversation about what needs to be done for this round, and a link to Hydra to see what's failing, etc. | 17:31:37 |
| Alyssa Ross | what old workflow? | 17:31:50 |
| Nick Hu | Maybe this is not true, but I believe that people used to just merge mass-rebuilds directly into master? | 17:32:17 |
| Alyssa Ross | I'm sure at some point they did! | 17:32:46 |
| Alyssa Ross | but not in my time (since 2018) | 17:32:52 |
 lukegb (he/him) | It's generally... frowned upon unless it's urgent | 17:33:16 |
| Alyssa Ross | yeah there is the occasional exception (like critical openssl vuln or something) | 17:33:30 |
| Nick Hu | Perhaps it's really my own ignorance, but I have never merged anything into staging before, so I assumed it was a new-ish workflow (been around since 2016 roughly) | 17:34:27 |
| Nick Hu | Then again, I seldom touch mass-rebuild packages | 17:34:42 |
| lukegb (he/him) | The nixpkgs doc section linked in the PR has a few words about staging/staging-next but not a whole lot | 17:34:53 |
| Nick Hu | In reply to @lukegb:zxcvbnm.ninja
The nixpkgs doc section linked in the PR has a few words about staging/staging-next but not a whole lot Yeah also I don't recall reading this before | 17:35:12 |
| Nick Hu | 
Download image.png | 17:36:20 |
| Alyssa Ross | I've found a reference to staging-next in a comment line that was added in 2018 | 17:38:40 |
| Alyssa Ross | so it's certainly been around for a while | 17:38:47 |
| Alyssa Ross | and I imagine staging existed on its own before staging-next | 17:39:59 |
| Alyssa Ross | but that's harder to grep for | 17:40:09 |
| Alyssa Ross | staging apparently already existed in 2015 | 17:43:31 |
| Alyssa Ross | (not trying to prove a point or anything here -- I just found the archeological question interesting :)) | 17:43:59 |
| Nick Hu | In reply to @qyliss:fairydust.space
(not trying to prove a point or anything here -- I just found the archeological question interesting :)) Me too! The earliest reference I can find is https://github.com/NixOS/nixpkgs/commit/b4e5181dde01c6938825484f210120b54f1a7d2a | 17:46:04 |
