That's great! What do you want to do?
There are currently 100 packages that are Python 3–ready upstream (that we know of), but not quite yet Python 3–ready in Fedora. These are labeled as "mispackaged" in PortingDB.
You can view the mispackaged packages ordered by their last activity, so you can pick one off the top and be relatively sure nobody is currently working on it. Alternatively, you can pick one of these packages, where the packager explicitly asked for someone to provide a patch since they don't have the time for it.
Now open the package in PortingDB (e.g. pymol): The M next to Fedora in the sidebar indicates that indeed we are dealing with a mispackaged package.
On the package page in PortingDB, look down the sidebar for the headline RPMs. There you will see all the RPM (sub)packages contained in this package. Sometimes there's just the base package, sometimes it has several subpackages. What we want to know is if there is a (sub)package for Python 3. If there is only a Python 2 (sub)package, then we know that this package needs to be ported.
However, sometimes you will find a package that is still mispackaged even though it already has a Python 3 (sub)package. In those cases, something isn't quite right. Usually the Python 3 subpackage depends on both Python 3 and Python 2. That is unfortunate, because it basically renders the porting effort null.
In either case, look a bit further down on the package page in PortingDB and find a link to the associated Bugzilla report (under Links→bug in the sidebar). Go there and join the discussion. Find out what's the status quo and if anyone is working on it. If not, be the one that submits a patch!
If you don't find a link to Bugzilla, you'll need to investigate the issue and file a bug yourself. A hint on the nature of the problem will usually be provided just under the Fedora heading on the package page.
When you submit your patch to the associated Bugzilla report (use the "Add an attachment" button), be sure to ask the assgned packager to review and push it. However, as maintainers can be unresponsive for long periods of time, let us know about your patch as well so we can push it if the maintainer is unable.
To let us know, edit the Blocks field of the Bugzilla report and add the string PY3PATCH-AVAILABLE (you can use space as a separator). That way it will appear in our tracking bug for packages with an available patch. If need be, we'll review your patch and push it for the maintainer.
After you've done the deed, you deserve your reward! Sadly, the hand of the King's daughter and half of all the kingdom has recently become unavailable (may vary upon location, ask your nearest royal family), but fret not, you can get a badge of honour!
Wait a day or two after the patch is pushed so that the package turns green in PortingDB. Then visit the wiki for Python 3 badges and add a row with your FAS username if it doesn't exist yet. Inside put a link to the Bugzilla report you helped resolve as well a link to the package on PortingDB. You can get 3 badges: for your 1st, 5th and also 10th resolved package!
If you think we forgot to award you a badge, please ping Miro Hrončok (IRC is preferred).
If packaging is just not your thing, don't despair! You can help also by providing information!
There are 889 idle packages which are currently only available for Python 2 and where we don't know of their Python 3–readiness upstream. Do you know that some of them in fact do support Python 3 upstream? Great news! You can let us know by filing a bug!
The 416 blocked packages are a bit similar, but not quite. These are Python 2–only packages that cannot yet be ported because some of their dependencies are still not ported to Python 3 in Fedora.
If you do know that some of these packages support Python 3 upstream, open the package here on PortingDB and look for the the Fedora headline in the left sidebar. If there's a ✔ next to it, we already know it's ready upstream. Otherwise, please let us know!
To make PortingDB aware that the package supports Python 3 upstream, please make a pull request on GitHub and provide the information by editing the data/upstream.yaml file. People not acquainted with git can edit the file directly on GitHub by clicking on the little pencil icon on the right side above the contents of the file. Add the following:
package-name: status: released links: bug: http://... homepage: http://... repo: http://... note: | This is a custom note. Please do NOT forget the '|' on the previous line, it's important.
Make sure to put the note inside the file in alphabetical order according to the package name. Including a link is required, chose either a bug, homepage or a repo link type (or a combination thereof). And the note can be any relevant text you wish or it can be omitted.
There are also some packages that just won't be ported, because they were obsoleted by a different package. For example the python package just won't be ported, because the python3 package came along.
If you know of a package which people should stop using and switch to a different one instead, please make a pull request on GitHub and provide the information by editing the data/fedora-update.yaml file. People not acquainted with git can edit the file directly on GitHub by clicking on the little pencil icon on the right side above the contents of the file. Add the following:
package-name: status: dropped note: | Suggested replacement: `other-package-name` You are also encouraged to add a text comment like so.
Make sure to put the note inside the file in alphabetical order according to the package name.
The vast majority of the 889 idle packages are projects that are not yet ported to Python 3 upstream. We in Fedora follow the upstream first rule. If we need to make a change to some software (like port it to Python 3), we need to go upstream and either help the upstream team in the endeavour or offer to make the change for them.
Pick an idle package you would like to work on (for example libopensync) and open it in PortingDB. Now you can click on the package name besides the blue Fedora logo towards the top of the page. This will take you to the corresponding entry in the Fedora Package Database and from there follow the link labelled upstream.
Sometimes, however, the upstream link gets broken. In that case go back to the package's page here on PortingDB. Follow the spec file link: what you'll see is a file with the metadata and building instructions for this package. Look for a line beginning with Source0: and try to use its URL (or part of it) to find the upstream project.
First, let's make sure porting is needed as occasionally the package may be already ported, we just don't know about it yet. Look through the information on the website, the issue / bug tracker, the readme files, perhaps even the commit history. If it really is already ported, file a Fedora bug!
Otherwise, check if someone is working on porting it, or if it is perhaps planned. If there is an issue / bug tracker try finding if someone opened a ticket for porting to Python 3. If not, open one yourself! If you find no issue / bug tracker, you can use plain old email. Offer your help with porting the software and await a response. If you want to be proactive, you can start porting and then offer a pull request, but beware in some cases it might not be accepted.
It may happen that you find the upstream is dead and the project orphaned. You can take the initiative and take over the project. Start a new repository on GitLab/GitHub/Bitbucket/what-have-you, copy the sources there and get to work!