Zulip setup coordination - Public Room Timeline

	Zulip setup coordination	88 Members
	Coordination to setup https://nixpkgs.zulipchat.com/, see https://github.com/NixOS/foundation/issues/143	31 Servers

Load older messages

Sender	Message	Time
21 Feb 2024
@delroth:delroth.net	(I don't)	16:53:01
Jonas Chevalier	that's fine. I'm thinking of the wider circle mostly.	16:53:44
infinisil	It's important for the people with permission to make the desired change to be in on it, so you need to know who to even ask	16:54:40
infinisil	For Nixpkgs this is fairly easy, but for other things not	16:54:52
infinisil	And this is what I'm going for with the proposal to have an open organisation	16:55:21
tomberek	hrm... perhaps related to the above discussion on being explicit about the structure and permissions of the org.....	16:55:23
infinisil	Fully agreed that we need to also establish a better process for making decisions though	16:55:32
Jonas Chevalier	for sure, these are complementary	16:56:09
infinisil	Btw I chatted with ronef yesterday, and he's also in favor of going ahead with that proposal	16:58:22
@delroth:delroth.net	In reply to @delroth:delroth.net really imo this just needs someone willing to start a discourse thread asking for objections, leaving enough time for contributors and active community members to participate, then figure out how to handle the eventual objections - the whole discussion about infra and the foundation are red herrings here, at least from infra we'll figure out how to execute the decision also, to be clear: the real problem comes if there are strong objections, and I have no solution to offer to that	16:59:31
@delroth:delroth.net	I don't expect it to be the case here	16:59:35
@delroth:delroth.net	but maybe I'm too disconnected from parts of the community to expect it :)	16:59:47
infinisil	To resolve controversy, I think we either need a leader (or a team) to have the authority to make the decision, and an RFC-like process otherwise	17:01:13
tomberek	If I was driving this specific decision, here's how I would think about it at this point. Infra is indicating that they could support. I'd ask them to check for any issues related to change in costs and come up with mitigation plan. Then I'd ask the Foundation if the relevant legal issues are addressed. Then we pause to see if there are major objections, bring it up in a few relevant venues. (this may derail into a values/philosophy dicussion). Then roll out a test with an independent Hydra and cache. Assess.	17:01:19
@delroth:delroth.net	I'd ask them to check for any issues related to change in costs and come up with mitigation plan. Speaking for infra: I don't expect it to be worth measuring / provisioning for in advance. Worst case we can roll back and regroup if it leads to infra issues.	17:02:25
@delroth:delroth.net	(tensorflow is heavy to build, yes, but how many chromiums do we build already?)	17:03:04
@delroth:delroth.net	but that's not really a meta enough discussion for this channel I guess, carry on :P	17:03:57
tomberek	I was thinking that the s3 cache could be impacted with far more large bundles being worked on..... but I'd be fine with proceeding with your assessment.	17:04:04
tomberek	With the shift toward supporting more redistributable packages, this could incur maintenance cost on the Nixpkgs effort. I'd check with people in Staging + "Nixpkgs-daily-ops" + NAT.	17:05:19
@apcodes:matrix.org	In reply to @tomberek:matrix.org If I was driving this specific decision, here's how I would think about it at this point. Infra is indicating that they could support. I'd ask them to check for any issues related to change in costs and come up with mitigation plan. Then I'd ask the Foundation if the relevant legal issues are addressed. Then we pause to see if there are major objections, bring it up in a few relevant venues. (this may derail into a values/philosophy dicussion). Then roll out a test with an independent Hydra and cache. Assess. frankly that does sound like a fairly good pragmatic approach to the issue at hand	17:05:42
	@emma:rory.gay left the room.	17:54:11
tomberek	Jonas Chevalier: but we're back to the original problem.... if you want someone to take on the responsibility of making such a decision and driving it, then the desire for such an outcome needs to be clearly stated at the project-level. This is not an isolated thing that a few people can independently decide on, because of the cross-cutting concerns and impacts. To answer your original question: "who can make the decision whenever we allow unfree packages to be built on Hydra or not?" you have a few options: an individual - not ideal, because making them responsible for fallout would be a poor outcome a team - infra is in the best position to do so (@infinisil: they have the technical permissions to make the changes and fix issues or clean up violations), but are unlikely to make this decision without a decision from elsewhere in the ecosystem. the board - would require making a "direction"-style decision, which they have stated as out of their scope RFC - making the shepherds responsible for fallout is also poor The Nix Teams Representatives group - perhaps the best out of the above options? It's new, but has started to make similar decisions.	18:05:22
@apcodes:matrix.org	Just a quick follow up one this one: The Nix Teams Representatives group? Where do I find more information on that one. I was not aware of it's existence.	18:27:18
tomberek	https://github.com/NixOS/teams-collaboration	19:10:26
infinisil	tomberek: RFC - making the shepherds responsible for fallout is also poor That's not right. The shepherds only decide over the RFC, and that only with transparency and plenty of time for the community to see and object to it. The shepherd team is only responsible for properly taking community feedback into account and that the RFC reflects that. The ones responsible for potential fallout are the ones implementing the RFC, which doesn't have to be the shepherds. And the ones implementing it also have the chance to say that the RFC can't be implemented as decided after all due to unforeseen problems.	19:39:10
tomberek	That is true. I skipped a step of reasoning. It is usually best for the deciders of something to also be the responsible ones. So in the RFC case, this principle will be hard to follow because we don't want the shepherds to end up with this particular responsibility, it's too much to ask.	20:01:00
tomberek	So, the next option in the RFC category is to have the split in roles you mentioned.	20:03:17
@delroth:delroth.net	In reply to @tomberek:matrix.org Jonas Chevalier: but we're back to the original problem.... if you want someone to take on the responsibility of making such a decision and driving it, then the desire for such an outcome needs to be clearly stated at the project-level. This is not an isolated thing that a few people can independently decide on, because of the cross-cutting concerns and impacts. To answer your original question: "who can make the decision whenever we allow unfree packages to be built on Hydra or not?" you have a few options: an individual - not ideal, because making them responsible for fallout would be a poor outcome a team - infra is in the best position to do so (@infinisil: they have the technical permissions to make the changes and fix issues or clean up violations), but are unlikely to make this decision without a decision from elsewhere in the ecosystem. the board - would require making a "direction"-style decision, which they have stated as out of their scope RFC - making the shepherds responsible for fallout is also poor The Nix Teams Representatives group - perhaps the best out of the above options? It's new, but has started to make similar decisions. re: infra, I'd like to separate "executing the decisions" from "making the decisions". infra has a lot of responsibilities for the former, but that doesn't mean we should do the latter. Of course sometimes we need to be consulted, and sometimes we should be able to tell people "this is literally impossible", but bar that I think our role as infra should be to support the projects that the community think should be done.	22:31:35
@delroth:delroth.net	maybe it's time to take a page out of the debian playbook and go for the worst system, except for all the others :) get committers to vote on stuff or something	22:32:02
@delroth:delroth.net	* maybe it's time to take a page out of the debian playbook and go for "the worst system, except for all the others" :) get committers to vote on stuff or something	22:32:32

Show newer messages

Back to Room ListRoom Version: 10