Here is the idea.
Currently, we number our patches according to https://fedoraproject.org/wiki/SIGs/Python/PythonPatches
All our commits in https://github.com/fedora-python/cpython on top of upstream tags have numbered prefixes such as 00486: . All patches in our spec files are declared with the same numbers, e.g. Patch486: 00486-....patch .
We would like to get rid of this numbering and create a new numberless mode that we could opt in to. In the numberless mode, all patches are declared in spec file as Patch:, no patch filenames or commit messages start with a numbered prefix.
Numberless Patch declarations are supported at least from RPM 4.15, RHEL 9.
We treat patch 189 specially, so we will only opt in to this on Pythons that no longer have that patch (3.10+). For now, we let older Pythons be as they are.
importpatches
When there are no numbered prefixes in commit messages in our GitHub cpython repo, assume we are operating in numberless mode. When there are numbered prefixes, assume we are operating in legacy, numbered mode. If there is a mixture, error out.
When determining the filenames of patch files in the legacy, numbered mode (current code), the script looks at the numbers and finds the existing patch filename in the spec, to maintain stable filenames. The numberless mode cannot do this, as there are no numbers to use for matching. Instead, it should create the patch filename from scratch, as if there were no patch files. When running in numberless mode for the first time, all patches are renamed to remove the numbers anyway, so additional changes to filenames are not more harmful. Unless the commit messages are changed, the patch filenames will remain stable again.
The script will gain a new option that will number the patches in spec Patch1:, Patch2:... declarations for RHEL 8 compatibility. The numbers will always start with 1 and go sequentially. Such numbers have no semantic meaning; they only exist for backwards compatibility with old RPM versions. The patch filenames will not have those numbers.
exportpatches
When patches in the specfile have no numbers in Patch declarations, no number prefixes in filenames, and commit messages, assume numberless mode. When Patch declarations in spec files have small consecutive numbers and the filenames and commit messages don't have them, assume numberless mode as well (see the RHEL 8 compatibility option for improtpatches). When operating in this mode, exporpatches should not add any numbers to commit messages (not even the RHEL 8 compatibility numbers).
When there are patches with numbers in patch declarations, filenames, and commit messages, assume legacy/numbered mode. Note that in this mode, it is possible that the patches at the end might not have numbers in filenames or commit messages, as it is possible to add a patch without them (and exportpatches currently handles that by inserting the number).
Here is the idea.
Currently, we number our patches according to https://fedoraproject.org/wiki/SIGs/Python/PythonPatches
All our commits in https://github.com/fedora-python/cpython on top of upstream tags have numbered prefixes such as
00486:. All patches in our spec files are declared with the same numbers, e.g.Patch486: 00486-....patch.We would like to get rid of this numbering and create a new numberless mode that we could opt in to. In the numberless mode, all patches are declared in spec file as
Patch:, no patch filenames or commit messages start with a numbered prefix.Numberless Patch declarations are supported at least from RPM 4.15, RHEL 9.
We treat patch 189 specially, so we will only opt in to this on Pythons that no longer have that patch (3.10+). For now, we let older Pythons be as they are.
importpatches
When there are no numbered prefixes in commit messages in our GitHub cpython repo, assume we are operating in numberless mode. When there are numbered prefixes, assume we are operating in legacy, numbered mode. If there is a mixture, error out.
When determining the filenames of patch files in the legacy, numbered mode (current code), the script looks at the numbers and finds the existing patch filename in the spec, to maintain stable filenames. The numberless mode cannot do this, as there are no numbers to use for matching. Instead, it should create the patch filename from scratch, as if there were no patch files. When running in numberless mode for the first time, all patches are renamed to remove the numbers anyway, so additional changes to filenames are not more harmful. Unless the commit messages are changed, the patch filenames will remain stable again.
The script will gain a new option that will number the patches in spec
Patch1:,Patch2:... declarations for RHEL 8 compatibility. The numbers will always start with 1 and go sequentially. Such numbers have no semantic meaning; they only exist for backwards compatibility with old RPM versions. The patch filenames will not have those numbers.exportpatches
When patches in the specfile have no numbers in Patch declarations, no number prefixes in filenames, and commit messages, assume numberless mode. When Patch declarations in spec files have small consecutive numbers and the filenames and commit messages don't have them, assume numberless mode as well (see the RHEL 8 compatibility option for improtpatches). When operating in this mode, exporpatches should not add any numbers to commit messages (not even the RHEL 8 compatibility numbers).
When there are patches with numbers in patch declarations, filenames, and commit messages, assume legacy/numbered mode. Note that in this mode, it is possible that the patches at the end might not have numbers in filenames or commit messages, as it is possible to add a patch without them (and exportpatches currently handles that by inserting the number).