Il giorno mar 28 feb 2023 alle ore 11:19 Yubiao Feng <yubiao.f...@streamnative.io.invalid> ha scritto: > > Append asuggestion: > - After a PR revert, we need to remove the label named "release-xxx", which > can alleviate the release manager's work
I think that it is up to the committer who merges the patch to cherry-pick immediately to the other branches. At that point you have enough context to merge the patch and for sure the committer knows the patch well. In Apache BookKeeper and in Apache ZooKeeper we have a script that does the merge against the target branch and then it allows you to cherry-pick the other branches. Delaying the merge too much makes things harder. By the way the main point in this email thread is that we should totally stop to do cherry-picks of stuff that it is not strictly needed Enrico > > 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 > >
