turn gerrit into a full project hosting solution

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by oswald.b...@gmx.de on 9 Jun 2011 at 7:17

[GoogleCodeExporter]

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#_projec
t_access_control_lists

Original comment by edwin.ke...@gmail.com on 9 Jun 2011 at 8:16

[GoogleCodeExporter]

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.

Original comment by oswald.b...@gmx.de on 10 Jun 2011 at 1:36

[GoogleCodeExporter]

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.

Original comment by sop@google.com on 14 Jun 2011 at 12:33

[GoogleCodeExporter]

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?

Original comment by oswald.b...@gmx.de on 21 Nov 2011 at 9:40