Personally, I think every repository should be under a user or group namespace. As a wise man once said, namespaces are one honking great idea -- let's do more of those! I know this has been discussed a lot (both on that ticket and, it seems, prior to that ticket), but I wonder how much code we could simplify if everything was always in a namespace. Right now there's a lot of complicated if statements and weird URL routing rules that could go away if we just enforced this behavior.

Are you still firmly in favor of repositories using the root namespace of the URL scheme?

I think it might not be the best idea to mention other big source code hosting sites here.

@jcline, I think that @pingou's reasoning regarding not wanting to force user namespaces for pagure.io is reasonable, and I personally like it.
With some types of projects, e.g. dotfiles, those are highly personal and indeed they should be in user namespaces. That's then also an option to do.

With other types of projects, for example Basset, which is a "community project" (I'm not a fan of that term, but for lack of a better one), Pagure's "no namespace" model does make sense as it makes it clear what the upstream repository is.
Personally, with a lot of projects on some of the bigger platforms, I'm always left searching for what is currently the primary place where everyone's work converges, as there are sometimes hundreds to thousands of forks, and I'm looking for the original. (and the "Fork of X" doesn't always work or appear).
With the community project model, I know that pagure.io/pagure is the real upstream, vs pagure.io/forks/puiterwijk/pagure, which is a fork.

Also, with the Pagure model, especially in recent versions, I really like that even the original owner of hte repo has the option to fork it himself. That way, I can keep the upstream repo clear from branches that are the result of a PR-based workflow.

With other types of projects, for example Basset, which is a "community project" (I'm not a fan of that term, but for lack of a better one), Pagure's "no namespace" model does make sense as it makes it clear what the upstream repository is.

I think it introduces far more problems than it solves:

• Projects with the same name. This happens all the time. If there's no namespacing, it's a first-come-first-serve deal with Pagure. That's very unappealing.

• Projects can fork for good reasons (dead upstream with unresponsive maintainers, for example). Now all of a sudden the /<reponame> vs /forks/username/reponame is very confusing. Forcing people to rename the project is not particularly nice. I don't want my development tools enforcing those sorts of choices.

• Significant code complexity

The "pros" don't really resonate with me. Because of the cons above, a project in the root namespace doesn't mean (to me) that it's the current upstream since it might be dead (and now it's consuming that name across the entire deployment). Keeping my development branches in a fork doesn't really matter to me since I clean up my branches as I merge.

Regardless, it's not my project to design and people seem to have strong feelings about this particular decision. Nothing in this PR jumps out at me, so if people want to go this direction, :thumbsup:.

With other types of projects, for example Basset, which is a "community project" (I'm not a fan of that term, but for lack of a better one), Pagure's "no namespace" model does make sense as it makes it clear what the upstream repository is.

I think it introduces far more problems than it solves:

• Projects with the same name. This happens all the time. If there's no namespacing, it's a first-come-first-serve deal with Pagure. That's very unappealing.

But pagure isn't really meant to host all projects in the great internet, is
it?

If it is, then we better start thinking on how to do some serious optimization
both in the software, how services are interacting and how we deploy it and we
should find a way to secure funding for it.

• Projects can fork for good reasons (dead upstream with unresponsive maintainers, for example). Now all of a sudden the /<reponame> vs /forks/username/reponame is very confusing. Forcing people to rename the project is not particularly nice. I don't want my development tools enforcing those sorts of choices.

One pattern you often see in github for example is that suddenly as a project
takes off a little, people create a group because, people are not comfortable is
using it under the original author's name.
So they are actually already "renaming" (although it is more like moving in this
example) the project.

Another point to this is that when you fork a project in the literal sense, not
the github one, because upstream is unresponsive or anything, most of the time
people will rename it anyway, simply because they won't be able to upload the
new(er) versions to say pypi, or cran or cpan, or bioconductor...

An example:
https://github.com/tBaxter/python-card-me forked from vobject at the time
upstream was unresponsive to be able to release the project to pypi.

• Significant code complexity

If we were to change the model now, we would have to handle the backward
compatibility, so I am not sure the complexity would be that much reduced.

The "pros" don't really resonate with me. Because of the cons above, a project in the root namespace doesn't mean (to me) that it's the current upstream since it might be dead (and now it's consuming that name across the entire deployment).

One reason (maybe) for which this doesn't resonate for you is that you keep
comparing it with github, try comparing pagure more to something like trac or
redmine.

I know the approach I took isn't perfect, github's one isn't either but I do
like it, I do think it makes sense for what I see pagure being (ie: not github,
there is basically no point in trying to be github).
However, a number of people have asked for this over time, I was first not
convinced and after giving more thoughts I thought this could be done and in a
way that doesn't affect pagure.io while allowing other people to mi-mic a
different workflow using the same tool. That's what this PR is meant to allow.

If this is really a problem, I would honestly be inclined is just closing it and
calling it a day. I thought I was being nice in going out my way to make it nice
for other people to use pagure differently from the use-case I envision, if
that's really an issue, then let's close this PR, close the corresponding ticket
and move on to more interesting topics, this has been debated at length already
and I don't think we'll come up with new arguments before a while.

But pagure isn't really meant to host all projects in the great internet, is
it?
If it is, then we better start thinking on how to do some serious optimization
both in the software, how services are interacting and how we deploy it and we
should find a way to secure funding for it.

I'm not suggesting that it should, but I don't think it should be explicitly designed to only work on a scale of a few hundred repositories.

If we were to change the model now, we would have to handle the backward
compatibility, so I am not sure the complexity would be that much reduced.

Yeah, but that compatibility code eventually goes away, whereas those host of 'if namespace and...' only grow and become more complicated.

One reason (maybe) for which this doesn't resonate for you is that you keep
comparing it with github, try comparing pagure more to something like trac or
redmine.
I know the approach I took isn't perfect, github's one isn't either but I do
like it, I do think it makes sense for what I see pagure being (ie: not github,
there is basically no point in trying to be github).

I never mentioned GitHub in my comments, but it is true GitHub does use namespaces. I doubt they regret that choice, although I do wonder if they regret not using more namespaces since usernames pollute their root namespace.

For Pagure, it's amplified somewhat. Want to add a new route in /? That'll be painful, since it might collide with a pre-existing project or group because the root namespace is polluted. Want to use Pagure with dist-git? I hope there aren't any packages that collide with any of the existing routes. I guess we'll have to use a namespace there anyway.

I'm confused by all the practical, technical problems with the current setup. Why are we making it so hard on ourselves?

However, a number of people have asked for this over time, I was first not
convinced and after giving more thoughts I thought this could be done and in a
way that doesn't affect pagure.io while allowing other people to mi-mic a
different workflow using the same tool. That's what this PR is meant to allow.
If this is really a problem, I would honestly be inclined is just closing it and
calling it a day. I thought I was being nice in going out my way to make it nice
for other people to use pagure differently from the use-case I envision, if
that's really an issue, then let's close this PR, close the corresponding ticket
and move on to more interesting topics, this has been debated at length already
and I don't think we'll come up with new arguments before a while.

By all means, merge this PR. What I'm proposing is that we head further down this namespace road.

But pagure isn't really meant to host all projects in the great internet, is
it?
If it is, then we better start thinking on how to do some serious optimization
both in the software, how services are interacting and how we deploy it and we
should find a way to secure funding for it.

I'm not suggesting that it should, but I don't think it should be explicitly designed to only work on a scale of a few hundred repositories.

Well my basic use-case for pagure is self-hosting so the risk of name collision
becomes quite lower.
That PR allows to use pagure more for public hosting and thus should allow
scaling to more repositories.

If we were to change the model now, we would have to handle the backward
compatibility, so I am not sure the complexity would be that much reduced.

Yeah, but that compatibility code eventually goes away, whereas those host of 'if namespace and...' only grow and become more complicated.

I'm not sure compatibility code would ever go away since we would be touching
the URL routing, so old URLs must remain usable, at all time.

One reason (maybe) for which this doesn't resonate for you is that you keep
comparing it with github, try comparing pagure more to something like trac or
redmine.
I know the approach I took isn't perfect, github's one isn't either but I do
like it, I do think it makes sense for what I see pagure being (ie: not github,
there is basically no point in trying to be github).

I never mentioned GitHub in my comments, but it is true GitHub does use namespaces. I doubt they regret that choice, although I do wonder if they regret not using more namespaces since usernames pollute their root namespace.

For Pagure, it's amplified somewhat. Want to add a new route in /? That'll be painful, since it might collide with a pre-existing project or group because the root namespace is polluted. Want to use Pagure with dist-git? I hope there aren't any packages that collide with any of the existing routes. I guess we'll have to use a namespace there anyway.

For dist-git we'll have namespace yes, if only to distinguish docker vs rpms vs
tests repos (if those remain as is).

I'm confused by all the practical, technical problems with the current setup. Why are we making it so hard on ourselves?

However, a number of people have asked for this over time, I was first not
convinced and after giving more thoughts I thought this could be done and in a
way that doesn't affect pagure.io while allowing other people to mi-mic a
different workflow using the same tool. That's what this PR is meant to allow.
If this is really a problem, I would honestly be inclined is just closing it and
calling it a day. I thought I was being nice in going out my way to make it nice
for other people to use pagure differently from the use-case I envision, if
that's really an issue, then let's close this PR, close the corresponding ticket
and move on to more interesting topics, this has been debated at length already
and I don't think we'll come up with new arguments before a while.

By all means, merge this PR. What I'm proposing is that we head further down this namespace road.

Thanks, will merge :)