| 10 Dec 2023 |
 raitobezarius | we can move back this discussion to #dev:nixos.org but I agree there's kinda an unfortunate lack of avenue to discuss this | 20:50:48 |
| raitobezarius | maybe #team-members:nixos.org ? | 20:50:56 |
 delroth | github issue /s | 20:51:01 |
| raitobezarius | In reply to @delroth:delroth.net
rule of thumb: if it has nothing to do with administrative stuff (as in, legal entity), financials, trademarks, etc. - it has nothing to do with the foundation it's usually good to use the foundation channel to sort out meta level conflicts I suppose | 20:51:15 |
| raitobezarius | (though it should be unrelated) | 20:51:20 |
 @joepie91:pixie.town | In reply to @raitobezarius:matrix.org
I spent some time thinking about alternatives but it seems irrealistic at the time to move the source of truth, that is, the permission bits and users in the NixOS GitHub organization in another silo of data I find it difficult to build a full mental picture in an ad-hoc conversation like this, and aside from it not really being on-topic for this room, it seems like trying to discuss this in such an ad-hoc manner here is not going to be a good thing for the energy levels of anyone involved. this is why I suggested clarifying it fully in an RFC that describes the full rationale - it gives the space and time to evaluate the rationale, and address specific points in a system that's more conducive to this sort of discussion | 20:51:35 |
| @joepie91:pixie.town | In reply to @delroth:delroth.net
rule of thumb: if it has nothing to do with administrative stuff (as in, legal entity), financials, trademarks, etc. - it has nothing to do with the foundation I have been previously instructed to bring meta governance issues to here | 20:51:42 |
| @joepie91:pixie.town | if we have a better room, I'm happy to move there | 20:51:52 |
 Julien | In reply to @joepie91:pixie.town
but the problem is that "what is actually currently happening" is a subjective view, and that not everybody agrees on what that view is, and this change would declare one of those conflicting views as the source of truth. that is what makes it a policy change Correct me if I am wrong, but there is no other way to contribute to nixpkgs than to open a PR with your github account, which mean if it gets merged your github handle will be permanently written in the git history | 20:52:24 |
| raitobezarius | Let's move to #team-members:nixos.org | 20:52:40 |
 infinisil | In reply to @joepie91:pixie.town
cc infinisil re: the RFC stuff above If you scroll down a couple replies you'll see that I agreed with it being an RFC | 20:52:42 |
| infinisil | https://github.com/NixOS/rfcs/pull/165#discussion_r1379148280 | 20:52:51 |
| raitobezarius | In reply to @infinisil:matrix.org
If you scroll down a couple replies you'll see that I agreed with it being an RFC this is not how I read it though | 20:53:14 |
| raitobezarius | but maybe that's a language barrier | 20:53:21 |
| infinisil | Ah, so I agree that it's fine to have an RFC for that, just not that the RFC itself should be the canonical place for the bootspec specification itself | 20:54:08 |
| infinisil | Agree that that discussion was a bit all over the place though and hard to read | 20:54:33 |
| @joepie91:pixie.town | infinisil: sorry, I should've been clearer; I read your comment to imply that RFCs should only be used for more or less immutable specification changes, ie. things which are not expected to change any time soon after being accepted/passed, but this doesn't match my understanding of the intent behind the RFC process (where the immutability refers to the RFCs themselves and it is entirely fine to quickly follow up with another RFC that re-changes a just-changed thing), and I wanted to sort this out :) | 20:54:39 |
| @joepie91:pixie.town | since it's important that everyone is aligned on what the RFC process is for and how it should work | 20:54:50 |
| @joepie91:pixie.town | In reply to @raitobezarius:matrix.org
Let's move to #team-members:nixos.org I cannot seem to talk there, unfortunately | 20:56:20 |
| infinisil | I think RFCs themselves should be immutable, giving all the arguments for a decision at a specific point in time. After an RFC is accepted, it should be implemented so that you don't need the original RFC text anymore | 20:57:07 |
| infinisil | * joepie91 🏳️🌈: raitobezarius: I think RFCs themselves should be immutable, giving all the arguments for a decision at a specific point in time. After an RFC is accepted, it should be implemented so that you don't need the original RFC text anymore | 20:57:28 |
| @joepie91:pixie.town | infinisil: right, so in conclusion, you were not opposed to the bootspec RFC being an RFC? | 20:58:10 |
| infinisil | I think we made a good example for a specification with https://github.com/NixOS/rfcs/pull/166 | 20:58:08 |
| @joepie91:pixie.town | * infinisil: right, so in conclusion, you were not opposed to the bootspec RFC being an RFC, as opposed to "just a PR"? | 20:59:38 |
| infinisil | In reply to @joepie91:pixie.town
infinisil: right, so in conclusion, you were not opposed to the bootspec RFC being an RFC? Indeed, I only doubted whether the extra overhead of an RFC is needed and worth it | 20:59:35 |
| infinisil | (and the above) | 21:00:04 |
| @joepie91:pixie.town | infinisil: right, on that point I would want to refer back to https://matrix.to/#/!CJXQiUGqNPcFonEdME:nixos.org/$s2h_thkms4LUz2L3K3Np7xc7f1HDde9aBPfEQKyx8Zg?via=nixos.org&via=matrix.org&via=fairydust.space then | 21:00:19 |
| @joepie91:pixie.town | I think it is important to err on the side of an RFC, to fully integrate the RFC process into community processes; in this case, expressing that doubt seems to have discouraged raitobezarius from making an RFC on another occasion | 21:00:53 |
| @joepie91:pixie.town | and that even 'easy' cases are worth doing as an RFC, to practice with and streamline the process, they'd just likely end up being uneventful ones | 21:01:21 |
| infinisil | Yeah true. There has to be a balance though, both extremes are not great | 21:02:28 |
