Pagure-devel January 2020

pagure-devel@lists.pagure.io

2 participants
2 discussions

Thoughts for Pagure 6.0
by Neal Gompa 26 Jan '20

26 Jan '20

Hey all, 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[1]. * 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 bit premature. * 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[2], 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? [1]: https://www.palletsprojects.com/blog/ending-python2-support/ [2]: https://pagure.io/pagure/pull-request/4483 -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

How do you audit your repos for spam or abuse?
by Andrew Engelbrecht 07 Jan '20

07 Jan '20

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, : ) Andrew

4 5

2024

2023

2022

2021

2020

2019

2018

Pagure-devel January 2020