Make cherry_picker configurable and customizable for other projects

[Mariatta]

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.

[brettcannon]

I don't see anything wrong with this. Would you have miss-islington read from a config and then call cherry_picker as appropriate? Or would you have cherry_picker be the one that takes the config?

[Mariatta]

I'm thinking we can pass in the path of the config file to cherry_picker. If the path is not provided, it will assume the default (CPython).
So miss-islington and current CPython contributors don't need to worry about configuring anything.

[asvetlov]

My 5 cents: better to not require the path-to-config passing into cherry_picker but do lookup for config file by the tool itself.
When I do manual cherry-picking of CPython PR I don't specify the path. I would not do it on manual cherry-picking of aiohttp PR as well.

[asvetlov]

Defaults should remain (use CPython settings) if no config file exists in the repo, sure.

[asvetlov]

Next question is what config file name should we support.
I'm inclining to [tool:cherry-picker] section in setup.cfg but we could provide .cherry-picker.ini or .cherry-picker.toml as well.

[Mariatta]

I'm thinking to go with cherry-picker.toml just because we already have a pyproject.toml :)

[asvetlov]

Hide the config maybe by <dot> prefix: .cherry-picker.toml.
Like .gitignore, .travis.yml and .pyup.yml.
I expect to don't see cherry-picker config on ls execution.

[Mariatta]

Sounds good.