I've chatted with @asvetlov regarding aio-libs and aiohttp project, specifically regarding the workflow of backporting PRs (ref aio-libs/aiohttp#2853). They have very similar workflow with CPython, but things are still done manually there. I figured automations like cherry_picker and miss-islington will be useful for them, and likely for other projects too.

Currently cherry_picker has a number of hardcoded values and assuming the repo is CPython.
We should be able to make those configurable via a config file, so it can be adapted to other projects.

The final goal of aio-libs is to have bot similar to miss-islington to automatically backport PRs, but it depends on cherry_picker to do the actual backporting.

Questions

Are we (core devs) comfortable with making cherry_picker more general purpose? What could go wrong?

Configurable items

Only these two things need to be converted from hardcoded values into configuration items. Maybe inside a yaml file.

• the name of the repo, instead of hardcoded to cpython.
• how to detect if cherry_picker is in the right repo? Currently to detect if we are inside CPython's repo, it does git log -r 7f777ed95a19224294949e1b4ce56bbffcb1fe9f. 7f777ed95a19224294949e1b4ce56bbffcb1fe9f is the hash of the first ever commit to CPython. This hash can be in a config file.

Readme should be updated, explaining how to configure things.

In addition, we are already considering adding configuration file for other purpose (https://github.com/python/core-workflow/issues/107).

What won't change

Will not support Python < 3.6.

Compatibility with core Python's workflow and miss-islington will always be priority.

Limitations

cherry_picker might not work for projects where their backport branch names are not in the format of X.Y. There is logic in place where we sort the backport branches, backporting to the newest branch first.