-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable GitHub Commit Access #41773
Comments
This morning, I received an invitation to join llvm/llvm-project. Does that mean we will not be allowed to push to llvm-zorg and llvm-test-suite (by default)? |
I was trying to start everyone out with the minimum permissions and then expand as needed. Do you have recommendations for other default repos besides llvm-zorg and llvm-test-suite?
The reason I did not create a team is that you need to be an organization member to be added to a team and organization members have some extra permissions within the project that outside collaborators don't have. |
Not right now, but just in case there will be a new repo in the future, do you want to add all contributors manually / with a script? Just ticking a box for a whole team would be much easier.
I think you are referring to this https://help.github.com/en/articles/permission-levels-for-an-organization? AFAICS members have the following permissions:
Is there anything else that "normal" contributors should not be allowed to do and that cannot be disabled? |
That does seem like a better way since Github allows username changes so if there is a new repo, and someone changed their Github username in the meantime, the invitation could fail (best case) or actually end up going to the wrong person. I think Github keeps old usernames as aliases for a few months, but the username itself is "free" and the alias is removed earlier if someone registers a new account with that username (IIRC). So while existing repos would correctly retain references to the right Github accounts, keeping a manual list as a basis for auto-invites seems like it could go out of sync over time. For SVN, restrictions by developer policy worked fine (I think?) and with Git, a lot of accidents would likely be prevented by just enforcing linear history and preventing merge commits (like that huge merge commit which made Phab go on an email sending frenzy). |
Thanks for compiling the list of differences this was very helpful. Other differences I found are listed here: I do agree that teams seem easier to manage. I still like having collaborators at this stage, because they default to the lower permissions. However, I would like to revisit this after the migration. |
If we need to make mass changes to commit permissions in GitHub in the future, we will pull the list of collaborators from GitHub and not from the manual file we have now in SVN. This file is just an easy mechanism for us to verify the GitHub accounts of existing SVN users, and not something that we will use forever.
|
Unless I'm missing something, all points are included in my list above (plus some).
Your call, but I don't really get the point of not doing it right from the beginning (without disadvantages that cannot be easily avoided). Especially if every committer needs to accept 3 invitations (llvm, test-suite, zorg) and will get more notifications in the future about becoming a team member and being kicked out of repos after becoming so. |
@tstellar Closing? |
Extended Description
We need to grant GitHub commit access to all current SVN committers.
The text was updated successfully, but these errors were encountered: