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

Reply via email to