So we're in the throes of developing what will become Pagure 5.9, but
I'd like to take a moment to talk about Pagure 6.0. As an upcoming
major version bump, this is an opportunity to make some world-breaking
changes that would be better for users of Pagure.
Here are some thoughts I have about what we should do for Pagure 6.0:
* Drop Python 2 support and raise the minimum version of Python to
3.6. Most of our dependencies have dropped Python 2 support with the
EOL on January 1. This includes Flask and related components.
* Along with the Python 2 support being dropped, switch all code using
trololio to use asyncio. We're only using trololio because we need a
consistent wrapper between now-dead Trollius for Python 2 and asyncio
for Python 3.
* Stop using the Gitolite backend by default, and use the built-in
"pagure" backend instead. This backend has been in use on pagure.io
for a while now and seems to work reasonably well. We may want to
consider ripping out Gitolite support, but I think that *might* be a
* Consider changing from our default recommended production setup with
mod_wsgi and apache httpd if we can identify a more performant
alternative setup. This may also help with making Pagure more
"cloud-native" (i.e. k8s-friendly) by default, too. Which leads to...
* Make an officially supported OpenShift and Kubernetes deployment
strategy. We've had a PR open for the better part of the year for
adding Helm charts, but there's still some base work that needs to
be done for officially supporting a containerized deployment option.
Do we also want to have an operator and list on OperatorHub.io?
All of these are just ideas/suggestions. We don't have to do any or
all of these things, but these are some of the things I think might be
good for Pagure 6.0. Feedback on these ideas are welcome, as well as
your own ideas or suggestions!
So, what do you all think? Any of these good? Any better ideas? Or am
I completely off-base here?
真実はいつも一つ！/ Always, there's only one truth!
Hello Pagure devel list,
Sorry if this isn't quite the right place for this question.
The FSF is looking into hosting our own Web based SCM service, possibly
using Pagure. We would like to how the pagure.io team handles spam,
abuse, and overly large repos on your site. We expect that this could be
an issue, and that it would be critical for keeping our new site alive
and well. Any input on this topic would be very helpful.
Thanks, : )