About unifying policies

[jaimergp]

In #119, it was proposed to not have different policies per resource and feedstock, and instead consolidate them in a single one. See #121 as a possible solution there.

IMO, the reason we have different policies for each resource is because they have different requirements (e.g. the open-gpu-server requires TOS approval first), and that's why they shouldn't be conflated.

Before we go with one or another, I'd like to consolidate the discussion here and then act accordingly.

cc @mgorny @h-vetinari @conda-forge/core

[h-vetinari]

There are two separate (or perhaps even: divergent) concerns:

• resources need to be provisioned independently, and may have specific rules (like agreeing to the TOS)
• feedstock maintenance needs to be able to trigger builds on all resources simultaneously

For the second point, let's imagine for argument's sake that the three resources for the pytorch feedstock (for linux, win, osx) would have disjoint sets of approved users. Then we'd need three separate commits from the respective groups every time for doing a full build across all three resources. This would clearly be unworkable in practice.

So in other words, feedstocks need the union of resources attached to a policy, but governance needs the intersection of approved users per resource.

That would also be my suggested approach here: be able to express that intersection between different sets of users. For the pytorch case, this would be the intersection of

.cirun/.access.yml

Line 42 in 2bdf7b5

users_from_json: https://raw.githubusercontent.com/Quansight/open-gpu-server/main/access/conda-forge-users.json

and

.cirun/.access.yml

Lines 104 to 112 in 2bdf7b5

	users:
	- wolfv
	- baszalmstra
	- Tobias-Fischer
	- hmaarrfk
	- h-vetinari
	- isuruf
	- mgorny
	- jeongseok-meta

This approach would lose some small amount of flexibility (having rights to one resource but not another), but in practice I think this is irrelevant.

[h-vetinari]

This is now implemented in #121; for now without any extra fancy yaml keys that would dynamically allow intersecting lists of users, but merely by doing it manually.