| 20 Jun 2023 |
 @ronnypfannschmidt:matrix.org | something fun and unique one could do with a system like nixos, is to have non gc roots of avaliable application versions that link to the state versions discoverable (like have a version of the old app, the new app and the migrate command, and the systemd service will pick the executable based on current state ) - classically this would be done with tagged container images | 11:57:10 |
 raitobezarius |
migrations as such need ot be kind of managed as involved service groups that may or may not share required rollbacks
yes but this is a metadata problem somewhat, right?
| 12:16:47 |
| raitobezarius |
for full safety you need service deployment granularity that enables migrations in steps where both older and newer versons currently avaliable can work with the data in question
if your app supports it, yes; if not, you don't need it, as long as you always know how to "rollback an app code" and "rollback an app data", this is the only thing you need and this can always be done if you know where all the state is and you have Nix semantics
| 12:17:43 |
| raitobezarius | (of course, caveats applies on app which relies on globally provided libraries such as GPU, but this is orthogonal to the whole discussion IMHO) | 12:18:01 |
| raitobezarius |
maintenance modes for the applications that can happen independ of the code deployment are going to be important as well
yes, maintenance mode is one of the low hanging fruit for those procedures, nixops had a PR which enabled many niceties on this, we discussed it again in nixos deployments but I don't think it went somewhere
| 12:18:34 |
| raitobezarius |
so starting points like "having restorable backups" are definitively nice to have but applications themselfes also need some extras
at least, they would prevent people losing all their bookmarks in nextcloud or losing all their docs in hedgedocs, because some contributors blindly believe that automatic rollback is fine because everyone is responsible and do backups (which is not totally true)
| 12:19:28 |
| raitobezarius |
something fun and unique one could do with a system like nixos, is to have non gc roots of avaliable application versions that link to the state versions discoverable (like have a version of the old app, the new app and the migrate command, and the systemd service will pick the executable based on current state ) - classically this would be done with tagged container images
this can already be achieved by manipulating nix profiles properly I believe
| 12:20:28 |
| raitobezarius | I'm not sure we would need to go further on that | 12:20:40 |
 @piegames:matrix.org | Given the stated intention and the fact that approving the PR in GitHub is more a formality than really required, I am going to start and announce FCP now (or at least today) | 12:37:36 |
 Growpotkin | I approve | 12:37:40 |
| @piegames:matrix.org | RFC 140 is now in FCP, Discourse announcement unfortunately cannot be made by me against prior knowledge | 12:56:30 |
| @piegames:matrix.org | * RFC 140 is now in FCP, Discourse announcement unfortunately cannot be made by me contrary to prior knowledge | 12:56:38 |
 infinisil | piegames: Well hexa just posted RFC 127 FCP into the Announcements category, not the RFC Announcements one: https://discourse.nixos.org/t/rfc-0127-fcp-nixpkgs-problem-infrastructure/29349 | 13:58:54 |
 hexa | I looked for a previous FCP announcement and it was posted there as well | 13:59:18 |
| hexa | I had no idea the other category existed | 13:59:25 |
| hexa | nor could I have posted to it | 13:59:32 |
| infinisil | Yeah, we previously ran into this same problem | 13:59:50 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
piegames: Well hexa just posted RFC 127 FCP into the Announcements category, not the RFC Announcements one: https://discourse.nixos.org/t/rfc-0127-fcp-nixpkgs-problem-infrastructure/29349 Oh wow, I didn't even notice | 14:00:03 |
| infinisil | What we could do is post a comment in https://discourse.nixos.org/c/announcements/rfc-announcements/22 | 14:00:07 |
| infinisil | I mean https://discourse.nixos.org/t/rfc-0140-fcp-simple-package-paths/28589 | 14:00:16 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
What we could do is post a comment in https://discourse.nixos.org/c/announcements/rfc-announcements/22 I tried, and nope | 14:00:24 |
| infinisil | Oh wow you cannot even reply to a topic posted there | 14:00:44 |
| hexa | contact ryantm | 14:00:48 |
| infinisil | This should be the job of the steering committee | 14:01:05 |
| @piegames:matrix.org | In reply to @hexa:lossy.network
I had no idea the other category existed Tbf it is now linked in the RFC repo's readme | 14:01:17 |
| @piegames:matrix.org | In reply to @infinisil:matrix.org
This should be the job of the steering committee I'd honestly rather just have permission. Don't burden them with trivial tasks like this | 14:02:08 |
 ryantm | Made it so anyone can post and reply there. | 14:25:40 |
| infinisil | Yay! piegames ^ | 15:03:56 |
 figsoda | In reply to @infinisil:matrix.org
piegames: Well hexa just posted RFC 127 FCP into the Announcements category, not the RFC Announcements one: https://discourse.nixos.org/t/rfc-0127-fcp-nixpkgs-problem-infrastructure/29349 I moved it | 15:14:33 |
| @piegames:matrix.org | In reply to @ryantm:matrix.org
Made it so anyone can post and reply there. Now I'd also have permsisions to reply to https://discourse.nixos.org/t/rfc-0140-fcp-simple-package-paths/28589 instead? Should I do that or a new announcement? | 15:27:11 |
