Nixpkgs Architecture Team - Public Room Timeline

	Nixpkgs Architecture Team	231 Members
	https://github.com/nixpkgs-architecture, weekly public meetings on Wednesday 15:00-16:00 UTC at https://meet.jit.si/nixpkgs-architecture	53 Servers

Load older messages

Sender	Message	Time
5 Feb 2023
infinisil	And another idea related to that: The shepherd team should be separate and be comprised of the code owners, they don't do the work, they only decide. This would be the NAT team for nixpkgs changes, the Nix team for Nix changes, etc.	18:34:32
@blaggacao:matrix.org	The own repo work flow is excellent and very close to our all prefecence, you might have seen that I recently posted a link in discourse to `frappe/gameplan`. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context, but havn't made my mind up, yet.	18:49:11
@blaggacao:matrix.org	* The own repo work flow is excellent and very close to our all prefecences. You might have seen that I recently posted a link in discourse to `frappe/gameplan`. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context, but havn't made my mind up, yet.	18:49:24
@blaggacao:matrix.org	* The own repo work flow is excellent and very close to our all prefecences. You might have seen that I recently posted a link in discourse to `frappe/gameplan`. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context as a research question, but havn't made my mind up, yet.	18:50:17
@blaggacao:matrix.org	* The own repo work flow is excellent and very close to our all prefecences. You might have seen that I recently posted a link in discourse to `frappe/gameplan`. I'm still evaluating, but I have a gut feeling that this would maybe further improve our workflows as it increases not only theoric but practical transparency by consistently structuring the conversation. Anyway, just want to mention that in this context as a research question, but haven't made my mind up, yet.	18:50:22
@blaggacao:matrix.org	This argument goes with the assumption that practical transparency is the most gentle and at the same time powerful push tactics of all, among other things.	18:52:14
@blaggacao:matrix.org	^^ which is btw, why I thing your work in the NAT is so powerful.	18:53:23
infinisil	The jumble of GitHub + Matrix + Discourse might not be the best, yes :P	18:56:36
infinisil	Still looking for more shepherds for https://github.com/NixOS/rfcs/pull/138 btw ;)	18:58:55
Winter (she/her)	What would a shepherd actually do for such an RFC, @infinisil?	19:02:50
Winter (she/her)	e.g. what is there to shepherd?	19:02:58
infinisil	Winter (she/her): https://github.com/NixOS/rfcs#shepherd-team	19:03:49
@blaggacao:matrix.org	Make a meeting and call for FCP, essentially? 😃	19:04:05
Winter (she/her)	Ah, I see.	19:04:21
infinisil	Arguably someone from the steering committee should also be a shepherd member, because they are "codeowners"	19:05:04
Winter (she/her)	Agreed -- maybe write that in the comments?	19:05:59
Winter (she/her)	* Agreed -- maybe write that in the comments, so they can see?	19:06:03
@blaggacao:matrix.org	For what it's worth now or later, I packages frappe/bench so interested parties could start playing around with `gameplan`, should they wish to.	19:21:51
@blaggacao:matrix.org	Thanks to ChatGPT for Nixpkgs this was super easy. 😃	19:22:32
@blaggacao:matrix.org	* For what it's worth now or later, I packaged frappe/bench so interested parties could start playing around with `gameplan`, should they wish to.	19:23:11
@blaggacao:matrix.org	In fact, in the spirit of RFC 140, the hardest part was to find the right folder (and some version overrides, to be honest).	19:27:06
@blaggacao:matrix.org	It just got harder and became an evangelization issue after playing a little with it. But that's borderline off topic, here, anyways.	23:42:32
6 Feb 2023
Gytis Ivaskevicius	Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718	14:29:54
figsoda	In reply to @gytis-ivaskevicius:matrix.org Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718 The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb flakes support)	14:56:25
figsoda	In reply to @gytis-ivaskevicius:matrix.org Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718 * The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb flakes support)	14:59:45
figsoda	* The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb support in nix)	15:02:43
infinisil	@room: The next meeting will take place in ~10 minutes, we'll be there to discuss RFC 140 - meeting link - live stream - meeting notes	15:21:39
Gytis Ivaskevicius	I can see a callPackage like pattern being lifted to the nix level (maybe in a separate repository core, kind of like nixpkgs.lib), but things like stdenv are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. No, I think this should stay part of nixpkgs. Just that users have a fool proof option to make package depend on whichever nixpkgs revision they feel like about the issue, I like the perSystem pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like nixosSystem, or even ootb support in nix) `perSystem` is not part of the idea, it's being addressed as a separate issue. Quite possibly differently	15:23:02
nbp	In reply to @figsoda:matrix.org The blueprints still looks very nixpkgs-esque to me I believe that we should not encourage people to depend on nixpkgs and this should be resolved in nix itself. I can see a `callPackage` like pattern being lifted to the `nix` level (maybe in a separate repository `core`, kind of like nixpkgs.lib), but things like `stdenv` are strictly nixpkgs, it having a breaking change in nixpkgs will cause this flake to break, and I'm not seeing anything that refers to nixpkgs in the flake outputs. about the issue, I like the `perSystem` pattern that flake-parts uses, maybe this can be supported in a more official way (something in nixpkgs like `nixosSystem`, or even ootb support in nix) Let's hope not, as my plan was to get rid of its crappy logic to make it trivially extensible.	15:25:10
infinisil	In reply to @gytis-ivaskevicius:matrix.org Hey guys, not sure what you guys are up to these days but I'd appreciate if you guys could follow up on this `blueprints` idea, maybe making it a standard in nix ecosystem https://github.com/NixOS/nixpkgs/pull/208020#issuecomment-1419168718 We're currently focusing on RFC 140 as the first major change, but after that's done and implemented we'll have to find the next thing to work on, which might be something from the future work section, from the other NAT issues or something else	15:26:09

Show newer messages

Back to Room ListRoom Version: 9