[Clo-devel] Proposed organization of projects, groups and members in GitLab for common-lisp.net
ehuels at gmail.com
Tue Feb 24 17:14:42 UTC 2015
Trying to keep the mail short; sent too many essays already :-)
So, some context regarding GitLab's structure:
- each project has:
+ one repository
+ at most one issue tracker
+ at most one wiki
+ at most one snippets archive
+ at least one member
- each group has:
+ one or more members
+ zero or more projects
- each user:
+ has zero or more projects
+ is a member of zero or more groups and/or projects with a certain
Now, every member of a group is automatically a member of the group's
I propose we map common-lisp.net's projects to gitlab's groups since our
projects can (and do) have multiple repositories.
Since our current projects don't distinguish in access level between
project members, we should map access level to the highest available: owner.
Our repositories map to GitLab's projects. All GitLab projects are owned
by a group if found in the /project filesystem hierarchy. All personal
repositories (those found in /home) will be directly owned to users. Users
may choose to assign others access rights other than reading.
The system's login accounts will map to GitLab users. GitLab group
membership will be determined using the current method of project
membership: being member of a certain group in the /etc/group file.
Then there's one aspect left not discussed: project visibility. All project
repositories (those found in the /project hierarchy) will be assigned to
public projects. All public user repositories (those found in
/home/<user>/public_html/* or those linked from /var/git/projects/users/*)
will be assigned public visibility. All other user repositories will be
assigned "Internal" visibility (visible only to logged-in users).
http:// <http://efficito.com/>efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock in.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the clo-devel