Consider reviewing some PRs and cutting a new release?

[Jackenmen]

Hi there, thanks for making (and maintaining) this cool project!

I would want to ask the maintainers of this project to consider reviewing at least some of the open PRs and cutting a new release. About a year ago I wanted to help out with cleaning out the issue tracker so I've made a bunch of PRs (some of which have already been merged but not released: #58, #61, #40) with fixes and enhancements. There has been no new release since November, and I feel like there's already a decent chunk of unreleased changes (other than my own PRs, there's also #63 adding support for --mirror) that could be made available to everyone using cherry-picker.

Here's the list of not-yet merged PRs that pass tests and aren't a draft:

• Allow specifying custom upstream remote name #35 which fixes Mark Shannon's issue:
  • cherry_picker hardcodes the name of the python/cpython.git repo #19
• Fix exit with bad state when backport branch already exists #39 which may fix miss-islington's error:
  • "ValueError: One can only abort a paused process." (see Fix cherry-pick aborting miss-islington#480)
• Fix --no-push related issues in --continue and --abort #43 which fixes my own issues:
  • cherry_picker --continue does not respect --no-push option #41
  • cherry_picker --continue after successful run of cherry_picker --no-push creates second commit #42
• Respect existing trailers (including co-author lines) when backporting #46 which fixes miss-islington breaking co-author trailers:
  • Respect existing co-author lines when backporting miss-islington#439
• Allow passing a base branch that doesn't have version info #70 which does not fix any CPython workflow-related issues but makes cherry-picker more usable for some people's workflows (mine included):
  • Consider laxing the requirements for maintenance branch names? #69

I personally think that the single most important PR here is #46 because the lack of attribution just plain sucks when it's really the only thing that as a contributor to an open source project you can expect.
#35 fixes an issue of a CPython's core developer so that would probably be good to have but there are some open questions in the PR for it which may not make it possible to review at the current point in time.
Other than that, I think that #43 probably makes the most important fixes as it makes cherry_picker easier to use when you have to resolve conflicts which is probably the only time when CPython's core developers have to actually use cherry_picker manually so making that process better is IMO helpful.
Personally, I have a stake in #70 but I don't imagine it being useful to a lot of people, and definitely not useful for CPython workflow so that's just on my wishlist 😄

I hope this summary is helpful.

I'm not trying to demand anything here, it is a voluntarily-maintained project. All I want is for you to consider my ask, nothing more :)

[ezio-melotti]

Thanks for putting this together. I left a few minor comments in some of the linked PRs.
cc @ambv, @Mariatta

[Jackenmen]

Since it's getting close to a year, I figured this might be the right time to bump this (also got a notification on #70 so I kinda got reminded of this). We're really just left with #70 which may have been partially reviewed by @Mariatta as I was requested to and made the changes on it but since it's been a year that will probably just need a fresh review. After that, someone (Mariatta or Łukasz, I guess?) would just need to cut a new release since there isn't anything else left from PRs.

[Jackenmen]

It's probably not worth keeping this open with 2.2.0 release that happened yesterday since there's only one PR on the list that hasn't been merged and that can be tracked in the PR itself. Thank you for working on getting the new release out, @Mariatta!