significant progress has been made on this feature on the 'namespace' branch upstream
* upstream issue https://pagure.io/pagure/issue/1231
* upstream branch https://pagure.io/pagure/tree/namespace
as it turns out this feature does not affect routing of existing projects - this relates only to a new feature whereby users can create read-only public repos without merge requests or tickets
however - the global namespace and existing "fake-namespace" feature (which allows a single '/' slash character in canonical repo names) are left in tact so this seems to be the way forward for notabug
use the existing "fake-namespace" behaviour for all repos
ensure that user and groups names are mutually exclusive
associate all repos explicitly with a user (or group psuedu-user) on the "create repo" form
validate "project name" on the "create repo" form and backend to disallow the '/' slash character and programatically prepend the 'username/' or 'groupname/' prefix to all repos upon creation
adjust the views to filter the leading 'username/' or 'groupname/' from the canonical repo names
in this way the global namespace would be "apparently" disabled and all repos would be "fake-namespaced" to a user or group
like: '/username/repo.git' or '/groupname/repo.git' - this is already transparent to the user as permissions are always applied per-repo
another approach may be to implicitly create a group for each user and implicitly add all the user's repos to that group - but it is not yet clear if there is any benefit to this approach - perhaps repos associated with a group have fine-grained permissions?
the upstream 'namespace' branch has been merged
https://pagure.io/pagure/pull-request/1282
as it turns out this feature does not affect routing of existing projects - this relates only to a new feature whereby users can create read-only public repos without merge requests or tickets
however - the global namespace and existing "fake-namespace" feature (which allows a single '/' slash character in canonical repo names) are left in tact so this seems to be the way forward for notabug
* use the existing "fake-namespace" behaviour for all repos
* ensure that user and groups names are mutually exclusive
* associate all repos explicitly with a user (or group psuedu-user) on the "create repo" form
* validate "project name" on the "create repo" form and backend to disallow the '/' slash character and programatically prepend the 'username/' or 'groupname/' prefix to all repos upon creation
* adjust the views to filter the leading 'username/' or 'groupname/' from the canonical repo names
in this way the global namespace would be "apparently" disabled and all repos would be "fake-namespaced" to a user or group
like: '/username/repo.git' or '/groupname/repo.git' - this is already transparent to the user as permissions are always applied per-repo
another approach may be to implicitly create a group for each user and implicitly add all the user's repos to that group - but it is not yet clear if there is any benefit to this approach - perhaps repos associated with a group have fine-grained permissions?
significant progress has been made on this feature on the 'namespace' branch upstream
the upstream 'namespace' branch has been merged
https://pagure.io/pagure/pull-request/1282
as it turns out this feature does not affect routing of existing projects - this relates only to a new feature whereby users can create read-only public repos without merge requests or tickets
however - the global namespace and existing "fake-namespace" feature (which allows a single '/' slash character in canonical repo names) are left in tact so this seems to be the way forward for notabug
in this way the global namespace would be "apparently" disabled and all repos would be "fake-namespaced" to a user or group like: '/username/repo.git' or '/groupname/repo.git' - this is already transparent to the user as permissions are always applied per-repo
another approach may be to implicitly create a group for each user and implicitly add all the user's repos to that group - but it is not yet clear if there is any benefit to this approach - perhaps repos associated with a group have fine-grained permissions?