#5370 Preparation for Release 5.13.4 and 6.0
Opened a year ago by wombelix. Modified 2 days ago

As mentioned in https://pagure.io/pagure/pull-request/5043#comment-182016, there is a pagure Release 5.13.4 planned before the next Major Release 6.0.

I would like to start preparing for those two milestones, which first requires some coordination.

@pingou I moved all open Tickets with Milestone 5.12, Coming 3 months and Coming 6 months to Milestone 5.13. I need your assistance, can you please go through the issues and decide if it can be closed, if you want to see it in 5.13.4 or 6.0 and then change the status / milestone assignment accordingly? Please do the same for the open issue in Milestone 6.0, if you see something that you want already in 5.13, please change the Milestone in the issue.

I would also also suggest to Archive the Milestones 5.12, Coming 3 months and Coming 6 months and to only keep and focus on 5.13 as well as 6.0.

Any ideas / suggestions how we tackle the backlog of ~600 issues?

I tried to get an overview and saw that a lot of them seem to be actual support tickets specific to src.fp.o, maybe it would help to create a label so we can easier see if it's something we have to work on from a general pagure perspective or not?

Other than that, I guess the only way to address the backlog would be going through each one and assign it to either Milestone 5.13 or 6.0?

I'm open for suggestions and happy for everyone who volunteers and help to bring a little more structure into the issues so we can start working in a transparent and coordinated way on the next releases.


@ngompa brought up that there was already some cleanup in regards to python 2 code in the master branch (https://pagure.io/pagure/pull-request/5043#comment-182225). Even though I was still open to doing some backporting / cherry-picking to support py27 again for an additional 5.13.x release, I changed my mind after doing some testing. Independent what already changed in the pagure codebase, it's already nearly impossible to get a working virtual environment with all old package versions together to perform the unit tests. The amount of work to then make everything compatible with py27 again is probably not worth the effort.

The time of Python 2 is long over and I think we have to accept that, I personally don't even believe that anyone is still running pagure on Python 2 at all.

That leaves us with two options:
1) Doing a 5.13.4 release that focus on bug fixes and is probably mainly what we have in the master branch today, but already drop Python 2 support.
2) Fully focusing on a 6.0 major release of pagure, scope still to be defined, which then requires at least Python 3.6, or even better python 3.8

There's already a 5.13.x branch for making new releases off that tree. So we'd cherry-pick from master to that branch to make a 5.13.4 release.

Python 3.6 must remain the minimum version for Pagure 6.0 since that's what RHEL 8 and SLE 15 ship.

I think in SLE 15 SP4 also Python 3.10 is available, but yeah at least in GA it's not the case, I don't mind to stick with 3.6, the unit tests with C8S and py36 are looking good so far.

Not sure how helpful I can be for a 5.13.4 release with py27 support, getting the unit tests stable again, without even thinking of such an old Python version, is already very challenging and time consuming, but I will try my best.

Hi,
just to give this information that can be useful

pagure version on Fedora 37, pagure-5.13.3-5.fc37.noarch , needs one fix from 2018 !

Thanks @sergiomb, I'm not an expert in Fedora Packaging but as far I can see the build is fine in the state as it is right now? Just to better understand your comment, why are the mentioned changes needed?

As far I can see, the only thing which is not yet in the master branch is PR 5043 right?

So when you say there are patches missing for pagure-5.13.3-5.fc37, it's about cherry-picking these three commits into https://src.fedoraproject.org/rpms/pagure/tree/f37 ?

And as soon https://pagure.io/pagure/pull-request/5043 was merged, those commits too.

As mentioned above, I'm not sure about the right process, should I create a separate Issue here to track the activities to get pagure-5.13.3-5.fc37 updated or what would be best approach?

There's already a 5.13.x branch for making new releases off that tree. So we'd cherry-pick from master to that branch to make a 5.13.4 release.

I would like to quickly double check on this one, do we really need to still support Python 2 in a 5.13.4 release and can only get rid of it with a major 6.0 version? For me this is still a little unclear, in some of the comments I had the impression that's urgently necessary, in others it sounded more like something optional.

There are no unit tests for py27 running anymore, probably since quite a long time, the lowest tested version is Python 3.6 on CentOS 8 Stream. Also I'm not sure about the use case, I guess none of the still supported OS versions only ships Python 2, everywhere at least Python 3.6 is available in the meantime?

My thoughts process is that we haven't done a pagure release in a long time and
there has been quite a few bugs fixed since that last release. So I'd say: cut a
5.13.4 release with all these bugs fixes.
It may not run on py2, but py2 is long gone, just like 5.13.3 or 5.13.2 we're
not testing py2 anymore, so we're not really claiming to be compatible, but have
also not officially removed support for it in the code (import six..., from
future ...).

In a 6.0, we can officially drop support for py2 and remove all the cruft that
was added to support both versions of python. 6.0 is also the opportunity to do
more clean up like dropping the support for gitolite or repospanner.

The advantage of doing a small release first is that it brings us back into the
habits of releasing, building and deploying the code.

My thoughts process is that we haven't done a pagure release in a long time and
there has been quite a few bugs fixed since that last release. So I'd say: cut a
5.13.4 release with all these bugs fixes.

Sounds good, based on the master branch as it is today or do you want to see other issues (see my initial comment) fixed as well before pushing 5.13.4?

It may not run on py2, but py2 is long gone, just like 5.13.3 or 5.13.2 we're
not testing py2 anymore, so we're not really claiming to be compatible, but have
also not officially removed support for it in the code (import six..., from
future ...).

Glad to hear that, makes it way easier :)

In a 6.0, we can officially drop support for py2 and remove all the cruft that
was added to support both versions of python. 6.0 is also the opportunity to do
more clean up like dropping the support for gitolite or repospanner.

The advantage of doing a small release first is that it brings us back into the
habits of releasing, building and deploying the code.

I guess to get a 6.0 release ready, we have a lot of work todo, should 5.13.4 the last release before the next major or do you want to release new bugfix / minors of version 5 every few weeks / months until 6 is ready?

Now that the unit tests are in a better shape (https://pagure.io/pagure/pull-request/5365), it should get easier to focus on actual bugs and features again.

What would help me as motivated contributor a lot would be getting some structure in our backlog and an overview what tasks to focus on for which release and timeline, so maybe that's something we could start doing?

Hi, could we get a new minor release with the latest changes? I want to avoid applying downstream patches.

Login to comment on this ticket.

Metadata