Python-maint user story

I’ve talked to @TomasTomecek yesterday and he encouraged me to file this issue. In here, I’ll try to describe a common problem we have in Fedora packaging of Python interpreters. We feel like there is a room for automation but so far we were unable to dedicate time for that. I’m not expecting that the packit team will see this, immediately jump for help and that we have a working solution for this next week. I see this simply as a point of reference for you (and us as well, as nobody tired to document this problem yet). However if you feel this is not an appropriate thing for packit, let me know soon, so we can start looking somewhere else.

cc @stratakis @encukou @hhorak

The task

A problem is found in Python. It may be a security problem a spec problem, anything. In order to fix it, the packager comes with a solution - backporting an upstream patch, adding a downstream only patch, adapting the specfile, etc. Sometimes, the problem is relevant for multiple Python versions on multiple Fedoras. In the worst case scenarios, all versions on all Fedoras. I remember once CVE fix where we needed to backport the same patch to all of those:

	Fedora 28	Fedora 29	Fedora master	EPEL 6	EPEL 7
Python 2.7	✓	✓	✓
Python 3.3	✓
Python 3.4	✓	✓	✓	✓	✓
Python 3.5	✓	✓	✓
Python 3.6	✓	✓	✓		✓
Python 3.7	✓	✓	✓

Now when 30 has branched, this would have been even harder. The upstream patch with the fix applied cleanly to all source trees, but we needed to backport the spec change to all of those. We utilize src.fp.o Pull Requests, so we gete the CI results, so this was in fact 19 pull request with the same content.

The automation

What I’d like to do is to open one PR (let’s say to python3@master) and indicate trough tags or comments that I want this backported somewhere else.

ok, packit, backport this all the way to f28

or

ok, packit, backport this to python{35…38} all the way to f29

Python upstream has an excelent GitHub bot called Miss Islington that does exactly that. See for example:

original: https://github.com/python/cpython/pull/12189 by bot: https://github.com/python/cpython/pull/12192

Clever backports

What I try to do when I backport something to an older branch:

1. I use fast-forward merge if possible
2. I cherry-pick if fast-forward is not possible

Sometimes, fast-forward would bring a “simple” unrelated commit and it is OK. This needs to be evaluated by a human, yet I don’t mind if the bot asks me: it can even open both PRs and let me decide.

Witch cherry-picking and cross-packages backports, the most annoying problem is conflicts in the %changelog. I suppose packit will try to solve this, if it brings back and forth sync between upstream spec and Fedora. The automation should figure out that the patch adds one changelog entry and bumps release by 1 and do the same in the other specfile.

(Note: @jkonecny12 aked me to try to get rid of changelogs in Fedora spec files and that would most likely help a lot with any sort of automation, but that’s not something that’s going to happen over a night.)

Another problem with cross-packages backports is the filename. The automation needs to figure out that if I’m changing python35.spec in python35 package, it is supposed to change python34.spec in python34 package.

On the other hand what I’m not proposing is for the automation to solve actual conflicts. If the backport is not solvable by a machine, that’s totally OK.

ok, packit, backport this all the way to f28

and the reply is OK to be:

f30 pull request: <link> f29 pull request: <link> f28 does not apply, do it manually

Looking beyond that

It would also be awesome if we could eventually utilize automation of the initial PR as well. Aka if I could run:

$ packit python3 backport 01e0f439f5009f37b95ab516e91906fcc7fcb8c3

And packit will check the python3 spec, find upstream git, locate patch 01e0f439f5009f37b95ab516e91906fcc7fcb8c3, git format-patch it, assign a number to it, add a comment parsed from upstream commit message (using some form of a template saved in to repo) and open a src.fp.o PR.

Combined with CI this would clearly reduce the time for a “simple backport” from 2 mandays to 20 seconds + 10 minutes review.

Thoughts?

[hroncok]

Here’s the thing:

1. I’ve been approached to submit this
2. I did
3. There was no request for more information
4. Suddenly a bot tells me this will be closed if no further activity occurs, yet I’m not the party that should produce the activity here, unless asked to

This seems a tiny bit hostile. However I do realize that that was not the intention.

[lachmanfrantisek]

Not closing EPIC would make sense.

Thanks for the feedback, we need to get used to it and tweak the config to match our needs.