The code does not have a strong maintainer anymore. Red Hat is no longer funding anyone to work on it and the volunteers who are working on it are over-committed to a dozen other things. This leads into the second problem
While it seems to work, it takes a lot of effort by various Infrastructure to keep it working at various times: New release of python. New features wanted to build tooling inside of the Fedora build system. New release of backend database requiring schema changes.
Pagure is a single node, single database system. This is a benefit and a problem. The benefits are that a lot of complex interactions with load-balancing do not show up which usually take even more developer and sysadmin time to debug. The bad-sides are that there isn’t any load-balancing of either the front end or the backend database. This limits the number of builds, commits, code views, CI checks, other database queries and other things.
Changes to the ‘business’ logic of how packages are built and images composed change every release. Like any ‘business’ logic, those changes tend to require all kinds of backend coding which affect multiple tooling. Not having an active maintained code base will cause the patching to be poor and needing constant rework at the worst time.
Those are the top level problems which are why looking at a replacement comes up over and over again. Fedora has a few dedicated engineers whose main job is to make sure that there are multiple composes done per day. The build system is highly complicated with many different tools tied together by stuff which needs constant maintenance because of logic changes.
I think what is meant here is that Pagure is far more in maintenance mode and not anyone’s or any team’s first priority. Pagure has served us well since Fedora moved to it, but we no longer have fulltime development of Pagure. That poses a risk for Fedora. We know that software changes and evolves and one component left in maintenance mode while everything around it continues to evolve is a risk.
Think of it similar to Fedora’s migration off IRC as a primary chat system. Why did we do that when IRC was working fine and had maintainers for clients and servers?
Going back to @jflory7’s point…is building a forge really what we want to do in Fedora? Is that the best use of time and resources we have?
That said, I do like Pagure and would like to see its development continue. But where we are in Fedora right now, we have outgrown what Pagure can do for us.
Pagure has never had substantial development resources behind it. Right now I think has about half a person working on it, and it’s not their official job.
Even outside of just the ‘keeping it running’ problems, It has a lot of deficiencies compared to enterprise-backed forges, to be honest. Its diffing and review interface is not up to snuff compared to github or gitlab; particularly its implementation of line-by-line reviewing is not great. Its CI integration…exists. Kinda. You can do it! I have done it for my projects! I wrote it up here! But the way you do it is…still more or less the way you did it four years ago when I wrote that, which is not exactly fun, and is substantially worse than e.g. gitlab CI.
Search is nowhere near as good as gitlab (which is nowhere near as github, which is ridiculously good). There are all kinds of paper cuts, like when you leave a comment and it fails to refresh the UI properly, or commit links in the activity log are wrong because the string parsing is broken. It’s just…clearly a very good attempt to build something like a professional forge with 1% of the resources you need to really build a professional forge. For what it is, it’s amazing! But…on an absolute scale it’s not great.
The main problem is that there is not a critical mass behind pagure. It does get some development, but it’s not enough. Pagure has some good things going for it - it started here, it’s consequently well-integrated, and it has some contributors, as this thread has illustrated. But we have to also acknowledge the scale of maintenance problems, that it continues to get further behind other forges in capabilities and fixes over time, that its maintenance record over the last several years has been poor. Many open issues are more than 5 years old and there are hundreds of open issues.
This isn’t the first time we’ve had this conversation, in fact the intent to leave Pagure has been understood for nearly 4 years, which is in itself a bit embarrassing, that it has taken so long. In that time there have been several valiant efforts to improve the state of Pagure, and indeed many issues did get closed out, but the pattern of unreliable maintenance remains. Also in that time alternatives like Forgejo have arisen, which may make a difference.
As we move through the alternatives evaluation I hope we can choose something that meets everybody’s needs, from the people who use it to the people who support its operation. A long time ago Red Hat + Cygnus sponsored Subversion development, but for most use cases we had to admit that git, which came later, was the better choice. Not every open source project gains critical mass. I suspect we all wish Pagure was one that did, but I hope in time we can acknowledge that others are better choices, and support their use instead.
