This sounds good. Would it make sense to create a PIP to document this proposal and possible decision that is later made when the proposal is approved?
I can find a PIP that is slightly related, it's https://github.com/apache/pulsar/wiki/PIP-47%3A-Time-Based-Release-Plan . It's probably not necessary to document all low level details in the PIP (like which script and solution gets used), but I feel that it would be useful to have the main principles and the "what?"/"why?" aspects covered. I also found a wiki page "Release process" https://github.com/apache/pulsar/wiki/Release-process . I guess all of these would have to be updated and consistent in the end after making changes to the way how releases are handled. How do changes like this usually get decided? Is the PIP (Pulsar Improvement Proposals) process meant to be used for this or is there some other way to decide? -Lari On Wed, Oct 28, 2020 at 12:52 PM Yong Zhang <zhangyong1025...@gmail.com> wrote: > Hi developers, > I want to introduce a command for cherry-picking PRs automatically. > > When we releasing a minor version of Pulsar, we need to cherry-pick the bug > fix PRs > into the release branch. Cherry-pick a lot of PRs will take a long time > and sometimes there has > some conflict need to resolve. > > I want to introduce a cherry-pick command which is similar to the rerun > test command to make the > cherry-pick process automatically. Ideally, after merging a PR, just need > to comment `/pulsarbot > cherry-pick this pr into branch-2.6`, then it will open a new PR to merge > into the `branch-2.6`. > > Open a new PR to do this will make that change also run the CI test in the > release branch > to ensure the branch can build successfully. And because the merged PR will > cherry-pick into > the release branch as soon as possible, we won't need to do the cherry-pick > when we release a > new minor version. That will reduce a lot of work for the committers. > > If you have any suggestions please let me know. > > Thanks, > Yong >
