About https://github.com/treeverse/lakeFS/issues/2491: while I disagree with the decision that we made, I am committed to it. So I am trying to use this issue in order to get some explicit arguments for our current design onto the record, which is probably https://github.com/treeverse/lakeFS/pull/2369 or the repo settings PR. My ideal resolution for this issue is to close it as "invalid". AFAIR @Itai Admi and I supported the kind of change that appears in #2491 in the F2F and written design reviews of protected branches. The general feeling in the room was against re-using existing mechanisms and instead creating a new mechanism, IIUC for simplicity of operation by users. However it is very likely I do not understand correctly. Most of all I want to maintain commitment to the agreed design. I agree that this is hard given the current state as documented, and I would be grateful if the people who best understand why we need a new mechanism would be willing to take the time to spell it out. But I do believe that we should continue the discussion if necessarily rather than re-open it, separately and with no context.

I agree, if there was a decision to go down this path, we shouldn’t revoke it if nothing critical was changed. I’ll close my issue, can someone add the arguments supporting the current design from that meeting?

@Itai Admi @Ariel Shaqed (Scolnicov) I remember it differently: what the team decided on (which Itai and Ariel objected to) was to use the backing storage for the branch-protection settings (and to develop a repo-level settings mechanism to support this). The other option was to store the settings in lakeFS, like we do for Actions. Itai's issue does not contradict the decision from the meeting. However, in a subsequent chat between Ariel and I, we discussed whether to strive for consistency in repo-level settings. The price for this would be adding complexity to our postgres model, which in the end we decided against. However this is not something we committed to as a team. While I personally think eventually consistent repo-level settings are perfectly ok, Itai's issue is still valid. Moreover, since repo-level settings use our branch locking mechanism - it will need to be replaced when we eliminate postgres - and Itai's suggestion sounds like a good direction to go. Does that make sense?