Nixpkgs Architecture Team - Public Room Timeline

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

Load older messages

Sender	Message	Time
9 Jun 2023
hexa	so I don't get what the fuss is about	17:17:57
@piegames:matrix.org	In reply to @infinisil:matrix.org piegames: So, the rfc process doesn't state who decides over whether the FCP needs to be cancelled: In most cases, the FCP period is quiet, and the RFC is either merged or closed. However, sometimes substantial new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into development mode. Ack. I'm leaning on the "sometimes substantial new arguments", because while the opposition has been in parts strong, I'd argue that being for a proposal but against a name in it is not substantial	17:20:05
infinisil	phaer: j-k: growpotkin ( Alex Ameen ): piegames: As shepherds of RFC 140, do any of you think niksnut's recent criticism is a substantial new argument that requires canceling FCP and potentially changing the RFC?	17:20:07
@piegames:matrix.org	Ha, good timing ^^ IMO it is neither new nor substantial	17:20:37
Eelco	I don't think it requires cancelling the FCP	17:21:53
Eelco	As long as people don't think that RFC saying "pkgs/unit" can be used as a blanket override of any objections on an eventual PR	17:27:42
Eelco	1 case of bad naming doesn't justify more bad naming. Quite the opposite.	17:28:41
hexa	certainly, to me sharding or partitioning captures the meaning better than unit	17:29:45
K900	I wasn't 100% following the conversation	17:30:14
K900	But was `pkgs/simple` proposed?	17:30:26
hexa	can you elaborate on the meaning?	17:30:53
hexa	* can you elaborate on the meaning of simple in that context?	17:31:06
infinisil	niksnut: The point of RFC's is to decide controversial things. If somebody has objections, now's the time to raise them. Once the RFC is accepted it's too late. I quote the RFC Readme: In general though this means that the implementation will be merged as long as there are no substantial technical objections to the implementation.	17:31:23
K900	Simple as in simple package paths, also simple as in simple to add	17:31:28
infinisil	In reply to @k900:0upti.me But was `pkgs/simple` proposed? I think that would imply that there's a complicated way to declare packages, which there currently is, but it's something we should get away from. Once we migrate everything, `simple` wouldn't mean anything anymore	17:33:20
Eelco	infinisil: The RFC process doesn't replace PR review. And "pkgs/unit" shouldn't get through PR review.	17:34:17
hexa	so at this time the RFC prefers a meaningless name over one with a meaning	17:36:00
@piegames:matrix.org	In reply to @hexa:lossy.network so at this time the RFC prefers a meaningless name over one with a meaning Some people do, personally I am fine with a meaningless name because any name is better than no name. And so far no satisfactory meaningful name has been brought up IMO	17:36:52
infinisil	There's a decent argument for `unit` by Robert Hensing (roberth) here: https://github.com/NixOS/rfcs/pull/140#discussion_r1170362174	17:37:51
infinisil	In reply to @niksnut:matrix.org infinisil: The RFC process doesn't replace PR review. And "pkgs/unit" shouldn't get through PR review. Even if you created Nix, I expect you to respect the community's RFC process, especially for Nixpkgs. If you were to block/revert the implementation of the RFC as it is stated, I consider that a violation of the RFC process.	17:40:18
Eelco	In that case I withdraw my statement about not having to cancel FCP	17:41:03
infinisil	Well, it's up to the shepherd team to decide whether it needs to be canceled	17:41:33
infinisil	K900: Oh apparently `simple` was proposed, see this linked thread	17:42:58
Eelco	For instance, if a shepherd team makes some bad decision about Nix, I wouldn't feel that the Nix team would be required to implement it. That's not how open source works. You can't force maintainers to accept technical decisions that they can't get behind.	17:43:13
infinisil	niksnut: Fully agreed, but in this case it's not Nix, it's Nixpkgs, which is fully developed by the community, there's no official global Nixpkgs maintainers	17:44:20
infinisil	niksnut: Also, in case something you couldn't technically accept for Nix were accepted in an RFC, I expect you to be able to raise "substantial technical objections" (cited from the RFC readme) to prevent such changes from being merged	17:46:29
@syphoxy:matrix.org	I'm not sure if the peanut gallery is allowed to suggest things, I will promptly delete my message if not, but would `pkgs/_XX` be a sufficient compromise to the `pkgs/unit/XX` debacle? that is, any 3 character directory starting with an underscore is considered to be a shard. the underscore would give off the feeling of being an internal data structure as well, which would bring in the nuance that someone suggested with "auto." it would also be lexically grouped together in this way. sorry in advance if I'm overstepping my bounds here.	17:58:48
infinisil	sy: No problem at all, suggestions are always welcome by anybody!	17:59:34
@syphoxy:matrix.org	* I'm not sure if the peanut gallery is allowed to suggest things, I will promptly delete my message if not, but would `pkgs/_XX` be a sufficient compromise to the `pkgs/unit/XX` debacle? that is, any 3 character directory starting with an underscore is considered to be a shard. the underscore would give off the feeling of being an internal data structure as well, which would bring in the nuance that someone suggested with "auto." it would also be lexically grouped together in this way. (strictly speaking, I find the idea of sharding for the sake of the GitHub UI to be unfortunate. I think it's weird that we're tying NixOS's design to GitHub's UX.) sorry in advance if I'm overstepping my bounds here.	18:00:20
infinisil	sy: Interesting idea, I can see some minor problems with it: Due to `_` being listed before the alphabet, it would cause all the `pkgs/top-level`, `pkgs/stdenv`, etc. to be moved to the bottom of the file listing File structures of repos should be considered internal by default, so a `_` could be interpreted as something that's even more internal, something that even developers of the repo shouldn't touch, maybe a bit exaggerated though	18:02:26

Show newer messages

Back to Room ListRoom Version: 9