| 30 May 2021 |
 m1cr0man | https://github.com/NixOS/nixpkgs/pull/124950 new PR in today. So, I'm unsure if this should be merged or not. I remember back in 20.03 there was discussions about key stapling (e.g. https://github.com/NixOS/nixpkgs/issues/84633#issuecomment-614584249) but I'm struggling to track down a specific ticket, it might have been in IRC. The use case was that you would have an app which you're shipping the public key with. That said, since the 20.09 patches where I introduced the hashed state folders we incidentally change the key regardless of whether --reuse-key is specified when the configuration changes. Anyone else got an argument for/against it? | 14:24:09 |
 hexa | One of the use cases for key reusal was HPKP, which was deprecated a while ago. I for one believe people should need to opt in to key reusal. | 14:36:03 |
| hexa | Needs to come with a changelog entry either way. | 14:39:49 |
| hexa | * Needs to come with a changelog entry either way. And to be fair, it is currently unnecessarily hard to drop the option. | 14:40:24 |
| hexa | * Needs to come with a changelog entry either way. And to be fair, it is currently unnecessarily hard to drop the option if you needed to. | 14:40:30 |
| m1cr0man | In reply to @hexa:lossy.network
Needs to come with a changelog entry either way. And to be fair, it is currently unnecessarily hard to drop the option if you needed to. On the logic alone of "It's hard to change" I think it makes sense to merge it. But yes, with a changelog | 14:44:03 |
|  Arian joined the room. | 14:48:40 |
| m1cr0man | Hi Arian :) | 14:50:05 |
| hexa | the remaining question would be: backport to 21.05 or not? | 14:51:02 |
| hexa | and by that matter: to which changelog to add this | 14:51:49 |
| m1cr0man | Would you not just add to 21.05 changelog when making the backport commit/PR? | 15:56:51 |
| hexa | needs to go into only one changelog though | 16:04:57 |
| hexa | so either backport to 21.05, then add it there | 16:05:06 |
| hexa | or keep it for 21.11 | 16:05:13 |
| hexa | should be part of the changelog were it was first introduced to endusers | 16:05:23 |
| m1cr0man | I see, ok | 17:45:47 |
| m1cr0man | Yeah I think we should backport, just to keep the modules similar between this and last release for ease of maintenance (if something bigger comes up) | 17:46:41 |
| m1cr0man | So would you simply not change the changelogs at all in this PR, or scrap it to make a backport? I dont think ive ever made a change that edited changelog + was backported :misc | 17:48:00 |
| m1cr0man | * So would you simply not change the changelogs at all in this PR, or scrap it to make a backport? I dont think ive ever made a change that edited changelog + was backported 😜 | 17:48:06 |
| hexa | add the changelog on for release-21.05 on master, then backport | 18:10:36 |
| hexa | the only way right now is to backport | 18:10:51 |
| m1cr0man | ok grand that makes sense | 18:15:10 |
| hexa | * add the changelog for release-21.05 on master, then backport | 19:06:26 |
| 31 May 2021 |
| m1cr0man | Derp.. didn't even check if he put it in the right changelog 🤦♂️ | 22:16:12 |
| hexa | right, and release is happening today | 22:18:53 |
| hexa | this is going great | 22:19:00 |
| m1cr0man | feck XD Well I was 14 hours late with my review anyway, he probably already went offline | 22:27:24 |
| m1cr0man | It wouldnt be the acme module if we weren't delaying release because of an open PR. Albeit, they are normally open for months before rather than a day | 22:29:13 |
| m1cr0man | And fwiw I dont think this one is a release-blocker. Practically all users will be unaffected by this | 22:30:33 |
| hexa | m1cr0man: I'M fixing this up now | 22:40:49 |
