-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make cherry_picker configurable and customizable for other projects #225
Comments
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? |
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). |
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. |
Defaults should remain (use CPython settings) if no config file exists in the repo, sure. |
Next question is what config file name should we support. |
I'm thinking to go with |
Hide the config maybe by |
Sounds good. |
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.
cpython
.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.The text was updated successfully, but these errors were encountered: