Perhaps we can document any known issues in the release notes with an indication of when they will be patched? That might help users determine whether to upgrade now or to wait for the next patch release.
Thanks, Michael On Mon, Apr 24, 2023 at 6:06 AM PengHui Li <peng...@apache.org> wrote: > > Yes, I just want to understand the process here and try to make it more > clear. > We'd better set a timeline for new feature fixes in the next feature > release. > After the timeline, we only accept fixes for security issues and > regressions. > > Thanks, > Penghui > > > On Mon, Apr 24, 2023 at 6:57 PM Christophe Bornet <bornet.ch...@gmail.com> > wrote: > > > Yes I agree that we should not ship buggy features. > > But also we decided on a time-based release plan so I'd be in favor of > > delaying features that are not fully tested to the next release. Hiding > > them behind feature flags if needed. > > If we do frequent, regular releases, this should not be an issue for users. > > Of course this must be discussed in the community and we should make the > > release process more clear about that. > > We learn as we do the things 🙂. > > > > > > Le lun. 24 avr. 2023 à 12:48, Enrico Olivelli <eolive...@gmail.com> a > > écrit > > : > > > > > > Il Lun 24 Apr 2023, 12:35 PengHui Li <peng...@apache.org> ha scritto: > > > > > > > Can we cherry-pick fixes for the new features that were introduced to > > > > 3.0.0? > > > > We do lots of chaos testing, stress testing for new delayed messages, > > and > > > > load balancer > > > > before the 3.0.0 release. Is it reasonable to have the fixes without > > > > releasing buggy > > > > features? > > > > > > > > > > > > > I 100% agree > > > But RM but be aware and they should do the cherry picks > > > > > > Enrico > > > > > > > > > > Or the testing should be completed before the code freeze, otherwise, > > push > > > > to the next feature release. > > > > > > > > Thanks, > > > > Penghui > > > > > > > > On Mon, Apr 24, 2023 at 6:08 PM Christophe Bornet < > > bornet.ch...@gmail.com> > > > > wrote: > > > > > > > > > Hi Zike, > > > > > > > > > > I just reverted the commits of PIP-195 (minutes before your mail 😄) > > > > > except for > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/e248e14473142765db1df324c20a081a2422980e > > > > > Maybe we should keep that one since it will be a breaking change if > > we > > > > > do it later. > > > > > > > > > > Le lun. 24 avr. 2023 à 11:52, Zike Yang <z...@apache.org> a écrit : > > > > > > > > > > > > Hi, all > > > > > > > > > > > > Based on the above discussion, I will revert all these commits. > > They > > > > > > are all related to the improvement of the PIP-195: > > > > > > * > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/e248e14473142765db1df324c20a081a2422980e > > > > > > * > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/e1d63990644700bf61b3d7af1ef6d4d62145c2bb > > > > > > * > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/ff59240165c73a9c3a3dcca20702ab44b0b18d33 > > > > > > * > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/49480ea558e647169e8df01bfd2e871a5386e19e > > > > > > * > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/1d1a3ef864a65c995ceda4b7875ed934c2574298 > > > > > > > > > > > > This commit has been reverted: > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/3da39b2e1553cecbc6d6b85e8bc7844f611d5637 > > > > > > > > > > > > And we keep these two commits for Pulsar 3.0.0: > > > > > > * > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/0df741259505b9189147d72c6f013b2c18f0436c > > > > > > * > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/d05871213adc351d4c718c2a6fb0909b01d279ff > > > > > > > > > > > > @Nicolò Could you provide more context for this commit: > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/e27abe9e128fb71b65ffe06417574c9a7f3facbd > > > > > ? > > > > > > Do we need to include it in Pulsar 3.0.0? > > > > > > > > > > > > Please let me know if you have any questions. > > > > > > > > > > > > Thanks, > > > > > > Zike Yang > > > > > > Zike Yang > > > > > > > > > > > > On Mon, Apr 24, 2023 at 5:23 PM Zike Yang <z...@apache.org> wrote: > > > > > > > > > > > > > > Hi, Michael > > > > > > > > > > > > > > Thanks for your explanation. I'm +1 for keeping these commits. > > > > > > > > > > > > > > Thanks, > > > > > > > Zike Yang > > > > > > > > > > > > > > On Sat, Apr 22, 2023 at 12:47 AM Michael Marshall < > > > > > mmarsh...@apache.org> wrote: > > > > > > > > > > > > > > > > > So to respect the code freeze, I propose to revert all those > > > > > commits except: > > > > > > > > > https://github.com/apache/pulsar/pull/19849 > > > > > > > > > https://github.com/apache/pulsar/pull/20086 > > > > > > > > > > > > > > > > Can you enumerate which commits you want to revert? 19849 was > > not > > > > > > > > cherry picked, so it is not relevant to this discussion. > > > > > > > > > > > > > > > > I feel strongly that we need to keep the following commits: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/370f6d7af78fa7bd8f92f8116fac4e3cf32adecb > > > > > > > > > > > > > > > > Justification: I broke the AuthenticationProviderList with my > > > > changes > > > > > > > > from PIP 97. This commit fixes that regression from 2.11. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/b839536cb05a0e1c737d9fb87edae1e054fd301b > > > > > > > > > > > > > > > > Justification: this fixes a broken error log to help users > > quickly > > > > > > > > identify a Kubernetes bug that users of the OIDC plugin will > > > > > > > > definitely encounter. I spent at least 4 hours earlier this > > week > > > > > > > > tracking down an issue that would have been obvious had the > > error > > > > log > > > > > > > > been correct. The change is very small and easy to understand, > > and > > > > > > > > will save users a lot of time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/0df741259505b9189147d72c6f013b2c18f0436c > > > > > > > > > > > > > > > > Justification: this is a one line bug fix that is necessary for > > > > OIDC > > > > > > > > to work in function pods. It is well understood and covered by > > a > > > > > test. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Michael > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Apr 21, 2023 at 5:27 AM Zike Yang <z...@apache.org> > > wrote: > > > > > > > > > > > > > > > > > > > I understand that the optimization PRs are nice but if we > > start > > > > > to > > > > > > > > > > accept them, why not accepting all the others and the code > > > > freeze > > > > > > > > > > becomes pointless. > > > > > > > > > > We can do a 3.0.1 shortly after to include all those > > > > > enhancements. > > > > > > > > > > > > > > > > > > Totally +1 for this. > > > > > > > > > > > > > > > > > > > The mailing list is too "slow" for this kind of stuff. For > > more > > > > > complex > > > > > > > > > > discussions, there's always the possibility to start a > > thread > > > > > here. > > > > > > > > > > > > > > > > > > I still recommend discussing the cherry-pick on the mailing > > list. > > > > > > > > > For the LTS release, we need to be very careful when > > > > cherry-picking > > > > > > > > > the commit. All cherry-picked commits that enter the LTS > > version > > > > > > > > > should be noticed for everyone. They should all be considered > > as > > > > > > > > > important changes. Another benefit of discussing it in the > > > > mailing > > > > > > > > > list is that we can keep the context of the cherry-pick > > > > > permanently. > > > > > > > > > > > > > > > > > > As long as we have a consensus, then any committers can > > > > > cherry-pick the commit. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Zike Yang > > > > > > > > > > > > > > > > > > On Fri, Apr 21, 2023 at 6:08 PM Cong Zhao < > > zhaoc...@apache.org > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > I agree with this, other PRs can move to 3.0.1. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Cong Zhao > > > > > > > > > > > > > > > > > > > > On 2023/04/21 09:43:20 Christophe Bornet wrote: > > > > > > > > > > > So to respect the code freeze, I propose to revert all > > those > > > > > commits except: > > > > > > > > > > > https://github.com/apache/pulsar/pull/19849 > > > > > > > > > > > https://github.com/apache/pulsar/pull/20086 > > > > > > > > > > > > > > > > > > > > > > I understand that the optimization PRs are nice but if we > > > > > start to > > > > > > > > > > > accept them, why not accepting all the others and the > > code > > > > > freeze > > > > > > > > > > > becomes pointless. > > > > > > > > > > > We can do a 3.0.1 shortly after to include all those > > > > > enhancements. > > > > > > > > > > > > > > > > > > > > > > Do we have an agreement on this ? > > > > > > > > > > > > > > > > > > > > > > Christophe > > > > > > > > > > > > > > > > > > > > > > Le ven. 21 avr. 2023 à 11:36, Cong Zhao < > > zhaoc...@apache.org > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > > > > I strongly agree that these cherry-pick should be > > notified > > > > > to the release managers to avoid unintended consequences. > > > > > > > > > > > > > > > > > > > > > > > > PR https://github.com/apache/pulsar/pull/20086 is to > > solve > > > > > a serious bug it will lead to the pulsar-io block, so it is very > > > > necessary > > > > > to cherry-pick into 3.0. The rest of the PRs are optimized for large > > > > > amounts of data, we also can discuss whether they are necessary to > > > > > cherry-pick into 3.0. > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Cong Zhao > > > > > > > > > > > > > > > > > > > > > > > > On 2023/04/21 07:26:43 Nicolò Boschi wrote: > > > > > > > > > > > > > I believe that currently there's no clear process in > > > > place > > > > > in order to > > > > > > > > > > > > > decide whether a commit should be cherry-picked into > > the > > > > > frozen branch. > > > > > > > > > > > > > I know that we have a slack channel for the release > > > > > coordination > > > > > > > > > > > > > #pulsar-release-3_0, which is open to everyone. > > > > > > > > > > > > > > > > > > > > > > > > > > One solution would be to let the release managers > > > > > cherry-pick the commits - > > > > > > > > > > > > > they are the contributors more focused on the > > stability > > > > of > > > > > the release > > > > > > > > > > > > > branch and they might be able to discuss if it's > > > > > worthwhile. > > > > > > > > > > > > > Their opinion is not more important than others, but > > they > > > > > need to know it > > > > > > > > > > > > > anyway and they could spot incompatibilities and > > avoid > > > > > unintended > > > > > > > > > > > > > consequences. > > > > > > > > > > > > > The mailing list is too "slow" for this kind of > > stuff. > > > > For > > > > > more complex > > > > > > > > > > > > > discussions, there's always the possibility to start > > a > > > > > thread here. > > > > > > > > > > > > > > > > > > > > > > > > > > When a committer would like to cherry-pick a commit, > > > > > instead of directly > > > > > > > > > > > > > going for it without any discussion, they can ask in > > the > > > > > release slack > > > > > > > > > > > > > channel. > > > > > > > > > > > > > The release managers will eventually cherry-pick it. > > > > > > > > > > > > > If there's no consensus then the discussion is moved > > to > > > > > the mailing list. I > > > > > > > > > > > > > believe this wouldn't happen often, considering that > > > > > currently we rely on > > > > > > > > > > > > > the common sense of committers. > > > > > > > > > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > Nicolò Boschi > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Il giorno ven 21 apr 2023 alle ore 07:58 Cong Zhao < > > > > > zhaoc...@apache.org> ha > > > > > > > > > > > > > scritto: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi Zike, > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm sorry for cherry-picking the new delayed > > message > > > > PRs > > > > > to branch-3.0. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Would be very grateful if we could get to 3.0 since > > it > > > > > is the new feature > > > > > > > > > > > > > > of the delayed message and has no impact on other > > > > > components. > > > > > > > > > > > > > > > > > > > > > > > > > > > > These PR is important to PIP-195, they will fix > > some > > > > > problem with the new > > > > > > > > > > > > > > delayed message and make this new feature work > > better. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Need to cherry-pick PR: > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20086 > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20111 > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20126 > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20136 > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20117 > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20155 > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20156 > > > > > > > > > > > > > > https://github.com/apache/pulsar/pull/20158 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > Cong Zhao > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2023/04/21 05:36:26 Zike Yang wrote: > > > > > > > > > > > > > > > Hi, all > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We found that there were a lot of commits that > > were > > > > > cherry-picked to > > > > > > > > > > > > > > > branch-3.0 without any discussion or notification > > to > > > > > reach a > > > > > > > > > > > > > > > consensus. Some PRs marked for the 3.1.0 > > milestone > > > > > were also > > > > > > > > > > > > > > > cherry-picked into branch-3.0. Here are the > > > > > corresponding > > > > > > > > > > > > > > > cherry-picked commits: > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/3da39b2e1553cecbc6d6b85e8bc7844f611d5637 > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/e248e14473142765db1df324c20a081a2422980e > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/e27abe9e128fb71b65ffe06417574c9a7f3facbd > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/e1d63990644700bf61b3d7af1ef6d4d62145c2bb > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/ff59240165c73a9c3a3dcca20702ab44b0b18d33 > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/49480ea558e647169e8df01bfd2e871a5386e19e > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/1d1a3ef864a65c995ceda4b7875ed934c2574298 > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/0df741259505b9189147d72c6f013b2c18f0436c > > > > > > > > > > > > > > > * > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/pulsar/commit/d05871213adc351d4c718c2a6fb0909b01d279ff > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > According to our release policy[0] and the code > > > > freeze > > > > > notification > > > > > > > > > > > > > > > [1], all commits that need to be cherry-picked > > into > > > > > branch-3.0 will > > > > > > > > > > > > > > > require reaching the consensus before > > cherry-picking. > > > > > > > > > > > > > > > Before cherry-picking the commit, we need to > > provide > > > > > the context for > > > > > > > > > > > > > > > why it needs to be cherry-picked into branch-3.0. > > > > Then > > > > > mark it with > > > > > > > > > > > > > > > the 3.0.0 milestone and raise the discussion to > > reach > > > > > a consensus. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would like to start a discussion regarding the > > > > > context for the above > > > > > > > > > > > > > > > cherry-picked commits. Should we include them in > > > > > Pulsar 3.0? > > > > > > > > > > > > > > > If there is still no consensus for the above > > commits, > > > > > we may need to > > > > > > > > > > > > > > > revert them before the RC3. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you have any questions or concerns, please do > > not > > > > > hesitate to let > > > > > > > > > > > > > > > us know. Thanks for your cooperation. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [0] > > > > > https://pulsar.apache.org/contribute/release-policy/#release-cycles > > > > > > > > > > > > > > > [1] > > > > > https://lists.apache.org/thread/43d28rtzsx7x3o4zd523jr5dmnczrn4h > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > > Zike Yang > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
