+1 Best Regards.
Jia Zhai Beijing, China Mobile: +86 15810491983 On Thu, Oct 29, 2020 at 9:02 AM Sijie Guo <guosi...@gmail.com> wrote: > > Would it make sense to create a PIP to document this proposal and > possible > decision that is later made when the proposal is approved? > > Proposals usually start with a discussion. If there is no major > disagreement, a PIP is usually required for documenting major changes. > > A vote thread is used for making a decision. > > > 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? > > A vote thread is required to make a decision. Lazy consensus is used for > adopting a change like this. > > - Sijie > > On Wed, Oct 28, 2020 at 12:17 PM Lari Hotari <l...@hotari.net> wrote: > > > 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 > > > > > >
