[ZF] A couple of github issues

Matthew Wilkes matthew at matthewwilkes.co.uk
Fri Feb 8 15:37:22 UTC 2013


Hi Jim, all,

> Can't admin users also add users to the team, including users who
> weren't already associated with the organization?

That's currently the case and would be true with the method I'm 
proposing, yes.

> - There are two teams, an admin team and a dev team.  The former
>    having Pull, Push and Admin rights, and the later having Push and
>    Pull rights.

No, there are three teams. Two are manually managed, these are the two 
you mention. There is also what I've been calling a 'stub team' which 
nominally has admin rights, but over no repositories. It's a bit counter 
intuitive, as GitHub uses bad names for its roles.

Being in the 'Owners' team gives you push, pull and admin on all 
repositories, but it ALSO gives you permission to administer teams and 
the organisation as a whole.

Being in a team that grants push, pull and admin, however, only grants 
you the ability to administer (i.e. delete, move, or add contributors 
to) individual named repositories. This is where our trick will happen.

> - The admin team is smaller than the dev team.

The Owners team will stay how it is now, that's right. It will be the 
people in charge of processing contributor agreements, for example.

> - The admin team is responsible for creating repos, which they them
>    move to the dev team.

Any members of the stub team will be able to create repositories. I'm 
suggesting that all the developers are in this stub team as well as the 
normal developers team. The script I've written will take care of 
managing the stub team, so we never have to touch it.

> - The dev can't delete repositories

That's right. Repositories that developers create automatically get 
assigned to the stub team, i.e. giving all those members access to 
administer them. However, every time the script runs (it takes a minute 
or so) it reassigns the new repository to the developers team, meaning 
only the Owners team can delete repositories more than a couple of 
minutes after creation.

> - The admin team can't delete repositories they've transfered to the
>    dev team.

Nope, they can.

> You seem to be especially concerned about deleting repositories.  I
> have to admit that I haven't been as concerned as I probably should
> be.  I've gotten a bit spoiled by subversion, which makes it
> impossible to truly delete anything.

The reason for that is that the closest I could get in the GitHub UI was 
what we want plus the ability for developers to delete arbitrary 
repositories. The idea of this script is to stop that happening.

> In general, the property of subversion that makes it impossible to
> delete data (other than by deleting the repo, which isn't possible by
> committers) has allowed us to be pretty liberal about accepting
> committers.

I think we should both try and prevent deleting of repositories (as this 
kills issue trackers and so on too) as well as do backups, as git does 
allow contributors to damage the history of a repo.


Just to try and make it clearer, here's the workflow that we'd do for 
adding a new contributor and a contributor creating a repo:

New contributor
===============

1. A member of the owners team, such as Tres or Andreas goes to github
2. They go to the repository settings page
3. Then the teams tab
4. They select the developer team
5. They add the new contributor
6. The mr.sisyphus script automatically adds the new contributor to the 
CanAdd team

New repo
========

1. A member has been added to the developer team
2. Therefore they're also in the CanAdd team
3. They can select the new repo button on github then choose zope-foundation
4. They create a new repo which GitHub associates with the CanAdd team
5. All developers gain have push, pull and administration rights on that 
repo by virtue of being in CanAdd
6. The mr.sisyphus script automatically disassociates that repo with the 
CanAdd team and associates it with the developer team
7. The push, pull, admin granted by CanAdd is removed, but all 
developers retain push and pull by virtue of being in the developer team.



Matt


More information about the foundation mailing list