> 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 > > >
