Issue 1008: turn gerrit into a full project hosting solution
Status:  New
Owner: ----
Reported by oswald.b...@gmx.de, Jun 9, 2011
think gitorious, github, etc.
given gerrit's extensive user/group and permission system, the actual review workflow system, and the to-be repository viewer ( issue #493 ), only very little is actually missing.  issue #203  covers half of the problem already. for further inspiration, see gitolite (or maybe gitosis), and possibly redmine for broader-scoped project management.

the most interesting feature is repository and branch management with fine-grained permissions and namespace separation. there are two basic concepts here:
- a personal namespace within a repository, think refs/personal/user/branch. this is relatively simple to manage and implement efficiently.
- personal (and shared) clones of repositories. these should use shared object stores (this dramatically reduces disk space requirements of the server and accelerates updating personal clones from mainline). additionally, clones should be visualized in the user interface, like branches within a single repository are. clones allow for cleaner separation and permission control.

it may be somewhat useful to be able to directly create changes for other repositories/branches from any given tree, but given gerrit's change submission concept, this is not very high priority (unlike on gitorious, where Merge Requests are a core feature).

project home pages, wikis, forums, a bug tracker and possibly other tools could be added at some later point, but it's probably sufficient to just provide hooks (some of which already exist) and examples how to hook other systems into it.

Jun 9, 2011
Project Member #1 edwin.ke...@gmail.com
Just to let you know, Gerrit already now supports a personal sandbox space per repository. To enable this feature for all developers you can e.g. assign privileges for 'refs/heads/sandbox/${username}/*'. Please find more details regarding this feature in the Gerrit documentation [1].

[1] http://gerrit.googlecode.com/svn/documentation/2.2.0/access-control.html#_project_access_control_lists
Jun 10, 2011
#2 oswald.b...@gmx.de
yes, that goes a long way already. what's missing here is that each user should be the admin for his personal space (be it branches or clones), i.e., he needs to be able to give other users access rights.
Jun 13, 2011
#3 sop@google.com
You already can give a user access rights to admin his own personal space, just grant Owner permission on refs/heads/sandbox/${username}/* to Registered Users. Each user will have owner access to all branches under their own namespace, and any subspace below it.

This isn't the same as having your own repository... but its close enough for many sites that want sandboxes for short-lived topic branches between developers.
Nov 21, 2011
#4 oswald.b...@gmx.de
ok, i finally tried it ...
unless i'm missing something, it's just no fun to use that without introducing a dynamic system group which always contains the effective owners of a particular namespace. should i create an issue for that?
but even that gets annoying once the owner wants to grant access to other users, as he has to mess with groups. so how about adding user-based access controls, too?