Append asuggestion: - After a PR revert, we need to remove the label named "release-xxx", which can alleviate the release manager's work
Thanks 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 >
