+1
Thanks On Oct 29, 2020, 12:27 PM +0800, Shivji Kumar Jha <shiv4...@gmail.com>, wrote: > +1 > > Regards, > Shivji Kumar Jha > http://www.shivjijha.com/ > +91 8884075512 > > > On Thu, Oct 29, 2020 at 8:29 AM Jia Zhai <zhaiji...@gmail.com> wrote: > > > +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 > > > > > > > > > > > > > >
