I agree that the `release/*` tags are misleading hints. Remove all the tags for the issued PR.
Best, tison. tison <wander4...@gmail.com> 于2023年2月28日周二 13:13写道： > For "what is breaking changes", at least the PULL_REQUEST_TEMPLATE gives > some hints: > https://github.com/apache/pulsar/blob/bbb543d8ed2b03361807c852da1a31cfb92939f3/.github/PULL_REQUEST_TEMPLATE.md?plain=1#L56-L72 > > For the issued PR, Hang commented at > https://github.com/apache/pulsar/pull/15914#issuecomment-1146942281 that > it changes the default behavior. > > An alternative is that the original PR author can hint a ! in title or > BREAKING CHANGE and commit message like conventionalcommits spec defines. > > Best, > tison. > > > tison <wander4...@gmail.com> 于2023年2月28日周二 13:07写道： > >> > The release manager is unable to review all PRs before releasing it. >> >> At least the RM is responsible for PRs cherry-picked he/she made. As we >> take compatibility in a high priority, if it's unclear a fix (patch) >> without breaking changes, the RM can ask for confirmation. >> >> Best, >> tison. >> >> >> PengHui Li <peng...@apache.org> 于2023年2月28日周二 12:45写道： >> >>> Hi enrico, >>> >>> +1 for your point. >>> >>> Do you know the details of the breaking change? >>> I can't find any discussions under the mailing list about the breaking >>> change. >>> >>> I have added the `release/important-notice ` label to the PR, and we >>> should >>> also discuss first, better to have a proposal if we are making breaking >>> changes. >>> >>> IMO, the main issue here is that the release manager doesn't know the PR >>> is >>> introducing breaking changes, rather than thinking that the introduction >>> of >>> breaking changes is reasonable to the patch release. I noticed Jason had >>> added the release/* label, I think he also isn't aware of the breaking >>> change. >>> >>> The release manager is unable to review all PRs before releasing it. >>> And the PR title said >>> >>> "[Fix][Tiered Storage] Eagerly Delete Offloaded Segments On Topic >>> Deletion". >>> >>> My impression, it also should be bug fix. >>> >>> Regards, >>> Penghui >>> >>> On Tue, Feb 28, 2023 at 10:32 AM Xiangying Meng <xiangy...@apache.org> >>> wrote: >>> >>> > Hi Enrico Olivelli, >>> > >>> > Totally agree, we should be careful when cherry-picking PRs. And we >>> can't >>> > trust our own judgment too much. For an uncertain PR, we must submit a >>> PR >>> > and wait for everyone to review it together. >>> > For example, for the PR [1] mentioned above, the measure I took was to >>> push >>> > a PR to cherry-pick and move it to the next release version (2.10.5) so >>> > that we have enough time to discuss and reach an agreement. >>> > >>> > Sincerely, >>> > Xiangying >>> > [1] >>> > >>> https://github.com/apache/pulsar/pull/19640#pullrequestreview-1315805022 >>> > >>> > On Tue, Feb 28, 2023 at 9:56 AM Yubiao Feng >>> > <yubiao.f...@streamnative.io.invalid> wrote: >>> > >>> > > Hi Enrico Olivelli >>> > > >>> > > Thank you for helping me correct my mistake >>> > > >>> > > Yubiao Feng >>> > > >>> > > On Mon, Feb 27, 2023 at 11:27 PM Enrico Olivelli < >>> eolive...@gmail.com> >>> > > wrote: >>> > > >>> > > > Hello Committers, >>> > > > I believe that we should stop cherry-picking breaking changes like >>> [1] >>> > > > to released branches. >>> > > > Really, this is something that we cannot do. >>> > > > >>> > > > When you decide to cherry-pick a commit to a "stable branch", >>> > > > currently branch-2.8, branch-2.9, branch-2.10 and branch-2.11 you >>> > > > always have to think about these things: >>> > > > - is it a breaking change ? >>> > > > - is it really needed ? >>> > > > - could it mine the stability of the branch ? >>> > > > >>> > > > The answer is usually that you can cherry-pick a change only if it >>> > > > falls into these categories: >>> > > > - there is a security hole to fix (in this case the PMC has to deal >>> > > > with it, and usually this is done not publicly) >>> > > > - there is a bad bug that cause data loss or other serious problems >>> > > > >>> > > > I have sent this message a few other times in the past. >>> > > > We, the Pulsar community, are responsible for the stability of the >>> > > > project and product that our users use in production. >>> > > > >>> > > > Even if you think that something that could "improve the >>> performance" >>> > > > or "do something better" is appealing you always have to keep in >>> mind >>> > > > that the risk of breaking something that is stable is too high in >>> > > > respect to the gain in terms of performances or anything else. >>> > > > >>> > > > Improvements should go only to the master branch, and users will >>> > > > benefit from them when we will cut a release. >>> > > > >>> > > > This is a free OSS project on which many users count on. >>> > > > >>> > > > If you are eager to see a performance improvement in your system, >>> then >>> > > > this is fine, >>> > > > this is OSS and you can legally have a fork and cherry-pick the >>> > > > patches and build it on your own. >>> > > > This is the reason why OSS is cool. >>> > > > But if you are able to cherry-pick a patch you are also able to >>> > > > maintain your fork and fix any problems if the patch caused a >>> > > > regression. >>> > > > >>> > > > Most of the consumers of OSS products rely on us because they don't >>> > > > have enough engineering resources to maintain such a project by >>> > > > themselves. >>> > > > >>> > > > They trust us and they won't scan a list of tens of commits in >>> order >>> > > > to double check if the upgrade will change the behaviour of their >>> > > > applications. >>> > > > >>> > > > This is Pulsar momentum, let's do our best to fulfill the >>> expectations >>> > > > of the companies that are adopting our project. >>> > > > >>> > > > Enrico >>> > > > >>> > > > [1] >>> > > > >>> > >>> https://github.com/apache/pulsar/pull/19640#pullrequestreview-1315805022 >>> > > > >>> > > >>> > >>> >>
