Skip to content
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

Closed
tstellar opened this issue Jun 27, 2019 · 8 comments
Closed

Enable GitHub Commit Access #41773

tstellar opened this issue Jun 27, 2019 · 8 comments
Labels

Comments

@tstellar
Copy link
Collaborator

@tstellar tstellar commented Jun 27, 2019

Bugzilla Link 42428
Version unspecified
OS Linux
Blocks #38741
CC @davezarzycki,@emaste,@hahnjo,@jryans,@LebedevRI,@RKSimon,@stephanemoore

Extended Description

We need to grant GitHub commit access to all current SVN committers.

@hahnjo
Copy link
Member

@hahnjo hahnjo commented Sep 21, 2019

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)?
If that was not the intention, I think it would make sense to put all contributors into a team. That way you can manage permissions more globally and add other repos if needed.

@tstellar
Copy link
Collaborator Author

@tstellar tstellar commented Sep 23, 2019

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?

If that was not the intention, I think it would make sense to put all
contributors into a team. That way you can manage permissions more globally
and add other repos if needed.

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.

@hahnjo
Copy link
Member

@hahnjo hahnjo commented Oct 3, 2019

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?

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.

If that was not the intention, I think it would make sense to put all
contributors into a team. That way you can manage permissions more globally
and add other repos if needed.

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.

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?

@llvmbot
Copy link
Collaborator

@llvmbot llvmbot commented Oct 11, 2019

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.

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).

@tstellar
Copy link
Collaborator Author

@tstellar tstellar commented Oct 11, 2019

Is there anything else that "normal" contributors should not be allowed to
do and that cannot be disabled?

Thanks for compiling the list of differences this was very helpful.

Other differences I found are listed here:
https://help.github.com/en/articles/converting-an-organization-member-to-an-outside-collaborator

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.

@tstellar
Copy link
Collaborator Author

@tstellar tstellar commented Oct 11, 2019

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.

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.

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.

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).

@hahnjo
Copy link
Member

@hahnjo hahnjo commented Oct 11, 2019

Is there anything else that "normal" contributors should not be allowed to
do and that cannot be disabled?

Thanks for compiling the list of differences this was very helpful.

Other differences I found are listed here:
https://help.github.com/en/articles/converting-an-organization-member-to-an-
outside-collaborator

Unless I'm missing something, all points are included in my list above (plus some).

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.

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.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 10, 2021
@asl
Copy link
Collaborator

@asl asl commented Dec 15, 2021

@tstellar Closing?

@tstellar tstellar closed this Dec 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants