| 28 May 2021 |
|  evils joined the room. | 17:55:05 |
| 29 May 2021 |
|  aaron joined the room. | 03:07:32 |
| 30 May 2021 |
|  l3af changed their display name from l3af to test. | 12:01:47 |
| l3af changed their display name from test to l3af. | 12:01:59 |
| l3af changed their display name from l3af to l3aft. | 12:11:09 |
| l3af set a profile picture. | 12:11:24 |
| l3af changed their display name from l3aft to l3af. | 12:11:58 |
| l3af changed their display name from l3af to l3af . | 12:13:27 |
| l3af changed their profile picture. | 12:13:36 |
| l3af changed their display name from l3af to l3af. | 12:28:35 |
| l3af changed their profile picture. | 12:28:46 |
 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 |
