<div dir="ltr"><div dir="ltr">On Sat, Jun 14, 2025 at 8:32 AM <<a href="mailto:eo10nd@duesdings.de">eo10nd@duesdings.de</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br></blockquote><div><br></div><div>Hi Nico,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> This has the unintented side effect that people that could commit directly to<br>
> their subteams area in SVN can no longer direct commit because git websites<br>
> are write protected for most people.<br>
> <br>
> For now please create Merge Requests and I will try to merge them ASAP.<br>
> <br>
> @sysadmin any idea how we can fix that so those who could commit to the l10n/<br>
> teams can still do it now?<br>
<br>
I'm not a sysadmin but generally what you (or the sysadmins) maybe can <br>
do is to allow everyone to merge Merge Requests into the master branch, <br>
but activate that a review by a code owner is required. And then you can <br>
create a CODEOWNERS file and write down the teams on the paths of their <br>
team pages.<br>
See <a href="https://docs.gitlab.com/user/project/codeowners/reference/" rel="noreferrer" target="_blank">https://docs.gitlab.com/user/project/codeowners/reference/</a><br>
<br>
You could also use push rules to limit teams to only change their <br>
directories, but it will probably be a bit more complicated than <br>
CODEOWNERS. Then they could even push directly to the master branch.<br></blockquote><div><br></div><div>Unfortunately both CODEOWNERS and Push Rules are features limited to the Premium and Ultimate versions of Gitlab (ie. the proprietary Enterprise Edition).</div><div>They are therefore not available to us.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Or you allow write access to the whole repo for all teams and intervene <br>
if the trust is violated.<br></blockquote><div><br></div><div>That has generally been the KDE model for handling instances like this.</div><div><br></div><div>If technical needs dictate, we can add some protection rules in our hooks.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
Nico<br>
<br></blockquote><div><br></div><div>Thanks,</div><div>Ben</div></div></div>