[Pagure-devel] Putting the Band back together - Road to Pagure v6.0

Hi fellow Pagure Community and Developer, I can only imagine how it was for you when CPE decided to adopt GitLab and basically to abandon Pagure [1]. It caused probably a lot of frustration, but I think it's also a chance to make Pagure better and more popular. I strongly believe that we need Pagure, a true Open Source gitforge with a lightweight, extensible and well designed code base. I'm writing you to bringing all Pagure enthusiasts back together, to get more communication going on the mailinglist and / or the IRC Channel, to cleanup the backlog, talk about the future of Pagure, the next major release and to do my part bringing the project back to life. A week ago I also wrote in the #pagure IRC Channel and got in touch with midipix and Conan Kudo that way. But who am I? My Name is Dominik, you can call me Dom, you find me online also as wombelix. I would describe myself as Open Source enthusiast and tech nerd, strong in a lot of areas like Linux, Automation but also programming in different languages. If you want to learn more about me, the link to my blog can be found in the Email signature. I explored Pagure ~1 1/2 years ago, tried to port it to FreeBSD, use it for my git repos and planned to contribute, but I was running out of time and had to postpone it. Life changed , I became a father, changed Job, but now it's time to finish the FreeBSD Port and finally get actively involved. I'm offering my help wherever needed and are committed to invest time on a regular basis. I would like to hear who else is still around and want to help. Based on the Feedback from midipix and what I see on pagure.io/pagure, going through the more than 600 open Issues and 20 Pull Requests, with the goal to close what's obsolete or already implemented, tag candidates for v6.0 and get better visibility, would be an important first step. Also allow me to quote from the email "Thoughts for Pagure 6.0" that Neal Gompa was sending on 26th January 2020 [2]: some > world-breaking changes that would be better for users of Pagure. I couldn't agree more! And when we take the shortage on active developers into account, removing as much legacy code and non-essential features as possible, would help to make further development and onboarding new contributors also way easier. Neal brought in his Email [2] further points up which should be part of the v6.0 discussion and planning: - Dropping Python 2 Support - Raising the minimum Python Version to 3.6 - Switching from trololio to asyncio - Using the build-in pagure backend instead gitolite - Consider moving away from mod_wsgi and Apache as recommend setup - Working on supported OpenShift and Kubernetes deployment strategies To sum it up, I suggest to first focus on the following topics: - Working on the Issues and PR Backlog - Fixing PR Jenkins CI Issues (every build is failing right now, even if there is no problem with the committed code) - Collecting and consolidating Ideas and Tasks for V6.0 Independent of that, I will also finish the FreeBSD Port and maintain it in future, it's a platform I like and it gives Pagure more visibility. I hope to hear from Pagure admins which are willing to grant me permissions, allow me to get further involved and from other community members which also want to contribute and make Pagure v6.0 possible. Cheers Dom [1] https://lists.pagure.io/archives/list/devel@lists.fedoraproject.org/threa... [2] https://lists.pagure.io/archives/list/pagure-devel@lists.pagure.io/thread... -- The Wombelix Post https://dominik.wombacher.cc