Re: [VOTE] PIP-282: Change definition of the recently joined consumers position

2023-12-24 Thread Yuri Mizushima
Close this vote by 3 binding +1.

Thanks,

-- 
Yuri Mizushima
equ...@apache.org

On 2023/12/19 11:10:45 PengHui Li wrote:
> +1
> 
> Thanks,
> Penghui
> 
> On Tue, Dec 19, 2023 at 3:58 PM Yubiao Feng
>  wrote:
> 
> > +1
> >
> > Thanks
> > Yubiao Feng
> >
> > On Tue, Nov 28, 2023 at 4:04 PM Yuri Mizushima  wrote:
> >
> > > Hi, Pulsar Community
> > >
> > > This thread is starting a vote for PIP-282.
> > >
> > > PIP design PR:
> > > https://github.com/apache/pulsar/pull/20776
> > >
> > > discussion thread:
> > > https://lists.apache.org/thread/69fpb0d30y7pc02k3zvg2lpb2lj0smdg
> > >
> > > Motivation
> > >
> > > Key_Shared has a mechanism called the "recently joined consumers" to keep
> > > message ordering.
> > > However, currently, it doesn't care about some corner cases.
> > >
> > > 1. [issue-1] The race condition in the "recently joined consumers", where
> > > consumers can be added before finishing reading and dispatching messages
> > > from ledgers.
> > > 2. [issue-2] Messages could be added to messagesToRedeliver without
> > > consumer-side operations such as unacknowledgement.
> > >
> > > We should care about these cases in Key_Shared subscription.
> > >
> > > Thanks,
> > >
> > > --
> > > Yuri Mizushima
> > > equ...@apache.org
> > >
> >
> 


Re: [DISCUSS] 2.10 EOL?

2023-12-24 Thread Zixuan Liu
Hi Michael,

The Pulsar release policy [0] defines the Pulsar 2.10 release line, which
has now been EOL. In fact, we still cherry-pick the commit to the
branch-2.10 from the master, see [1].

I think the Pulsar 2.10 has been stable in the past few years, and can be
run by using the JDK 8(Recommended version is JDK 11). The Pulsar 3.x
requires the JDK 17.

For enterprises to migrate JDK and Pulsar, they need to bear a significant
cost.

If we consider releasing the 2.10.6, I am willing to bump the Pulsar 2.10.6.

[0] https://pulsar.apache.org/contribute/release-policy/#supported-versions
[1] https://github.com/apache/pulsar/commits/branch-2.10/

Thanks,
Zixuan


Michael Marshall  于2023年12月19日周二 14:26写道:

> Hi Pulsar Community,
>
> Do we consider the 2.10 release line EOL? If not, is there a committer
> that would like to volunteer to release 2.10.6?
>
> We briefly discussed keeping 2.10 alive in June [0], and that was
> followed by a 2.10.5 release in July. Given that we already have 2.11,
> 3.0, 3.1, and now a discussion on 3.2, it seems unsustainable to keep
> 2.10 going much longer.
>
> Thanks,
> Michael
>
> [0] https://lists.apache.org/thread/w4jzk27qhtosgsz7l9bmhf1t7o9mxjhp
>


Re: [DISCUSS] Removing Pulsar-Trino plugin from main repo and call for volunteers to maintain it

2023-12-24 Thread Yubiao Feng
+1

Thanks
Yubiao Feng

On Sat, Dec 23, 2023 at 1:09 AM Matteo Merli  wrote:

> I want to start a discussion regarding the removal of all the code related
> to the Trino (PrestoDB) plugin from the Pulsar main repository.
>
> This topic was already discussed and approved long time ago in PIP-62 (
>
> https://github.com/apache/pulsar/wiki/PIP-62%3A-Move-connectors%2C-adapters-and-Pulsar-Presto-to-separate-repositories
> )
>
> The main reasons for not having Presto plugin as part of the main
> distribution of Pulsar were (and still are valid):
>
>  1. We need to ship the entire Presto runtime which is ~400 MB. This makes
> our tgz and Docker images huge
>  3. There is no strict need for this component to be in the same
> distribution / image: it could easily be provided in a different release
> tgz or Docker image
>
> Though I think that since then it became more clear that the current state
> of this plugin has been stagnating over the years.
>
> 1. There are not many active users of Pulsar-SQL component (I'd be very
> happy to be contradicted here)
> 2. The plugin code has not been improved in a long time
> 3. There are several open security issues (actually, almost the totality of
> current dependencies issues are today coming from Trino).
>
> My suggestion would be that, if there is any volunteer willing to pick this
> plugin up and maintain it in a separate repository (within the Apache
> Pulsar project) and with a separate release schedule, we should go ahead
> and move it.
> If there are no volunteers, we should just remove it as it is. If later on
> we want to revive it, we can always import the code from the last commit.
>
> Thoughts?
>
>
> --
> Matteo Merli
> 
>


Re: [DISCUSS] Removing Pulsar-Trino plugin from main repo and call for volunteers to maintain it

2023-12-24 Thread PengHui Li
+1

Regards,
Penghui

On Mon, Dec 25, 2023 at 10:06 AM guo jiwei  wrote:

> yes, +1 agree
>
>
> Regards
> Jiwei Guo (Tboy)
>
>
> On Sat, Dec 23, 2023 at 11:37 AM Matteo Merli 
> wrote:
>
> > Good point. I have created a PR here:
> > https://github.com/apache/pulsar/pull/21795
> >
> > We can always cherry-pick changes into the release branch, during the
> code
> > freeze, with the appropriate precautions :)
> >
> > Matteo
> >
> >
> > --
> > Matteo Merli
> > 
> >
> >
> > On Fri, Dec 22, 2023 at 9:41 AM Lari Hotari  wrote:
> >
> > > Do we target release 3.2.0 if this change gets accepted?
> > >
> > > The code freeze for 3.2.0 was about to start today and I blocked that.
> I
> > > removed the already started branch-3.2 (which didn't contain any
> changes)
> > > until the decision has been made. I hope this makes sense. If not, we
> can
> > > always cut the branch again, nothing has been lost.
> > >
> > > re: https://lists.apache.org/thread/0pl9by5c53nkjp7vld3x89c8nqjrx9on
> > >
> > > -Lari
> > >
> > > On 2023/12/22 17:09:19 Matteo Merli wrote:
> > > > I want to start a discussion regarding the removal of all the code
> > > related
> > > > to the Trino (PrestoDB) plugin from the Pulsar main repository.
> > > >
> > > > This topic was already discussed and approved long time ago in
> PIP-62 (
> > > >
> > >
> >
> https://github.com/apache/pulsar/wiki/PIP-62%3A-Move-connectors%2C-adapters-and-Pulsar-Presto-to-separate-repositories
> > > > )
> > > >
> > > > The main reasons for not having Presto plugin as part of the main
> > > > distribution of Pulsar were (and still are valid):
> > > >
> > > >  1. We need to ship the entire Presto runtime which is ~400 MB. This
> > > makes
> > > > our tgz and Docker images huge
> > > >  3. There is no strict need for this component to be in the same
> > > > distribution / image: it could easily be provided in a different
> > release
> > > > tgz or Docker image
> > > >
> > > > Though I think that since then it became more clear that the current
> > > state
> > > > of this plugin has been stagnating over the years.
> > > >
> > > > 1. There are not many active users of Pulsar-SQL component (I'd be
> very
> > > > happy to be contradicted here)
> > > > 2. The plugin code has not been improved in a long time
> > > > 3. There are several open security issues (actually, almost the
> > totality
> > > of
> > > > current dependencies issues are today coming from Trino).
> > > >
> > > > My suggestion would be that, if there is any volunteer willing to
> pick
> > > this
> > > > plugin up and maintain it in a separate repository (within the Apache
> > > > Pulsar project) and with a separate release schedule, we should go
> > ahead
> > > > and move it.
> > > > If there are no volunteers, we should just remove it as it is. If
> later
> > > on
> > > > we want to revive it, we can always import the code from the last
> > commit.
> > > >
> > > > Thoughts?
> > > >
> > > >
> > > > --
> > > > Matteo Merli
> > > > 
> > > >
> > >
> >
>


Re: [VOTE] PIP-326: Create a BOM to ease dependency management

2023-12-24 Thread PengHui Li
+1 (binding)

Regards,
Penghui

On Sat, Dec 23, 2023 at 12:18 PM houxiaoyu  wrote:

> +1 non-binding
>
> Best,
> houxiaoyu
>
> tison  于2023年12月23日周六 10:10写道:
>
> > +1 binding
> >
> > Best,
> > tison.
> >
> > 太上玄元道君  于2023年12月23日周六 09:06写道:
> > >
> > > +1 nonbinding
> > >
> > > Umut Bilal Okur 于2023年12月23日 周六00:13写道:
> > >
> > > > +1 (non-binding)
> > > >
> > > > Enrico Olivelli , 22 Ara 2023 Cum, 18:26
> > tarihinde
> > > > şunu yazdı:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > Enrico
> > > > >
> > > > > Il giorno ven 22 dic 2023 alle ore 02:46 Apurva Telang
> > > > >  ha scritto:
> > > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > On Thu, Dec 21, 2023 at 4:30 PM Matteo Merli 
> > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Matteo Merli
> > > > > > > 
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Dec 21, 2023 at 4:24 PM Nicolò Boschi <
> > boschi1...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 binding
> > > > > > > >
> > > > > > > > Nicolò Boschi
> > > > > > > >
> > > > > > > >
> > > > > > > > Il giorno gio 21 dic 2023 alle 21:21 Lari Hotari <
> > > > lhot...@apache.org>
> > > > > ha
> > > > > > > > scritto:
> > > > > > > >
> > > > > > > > > +1 (binding)
> > > > > > > > >
> > > > > > > > > -Lari
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, 21 Dec 2023 at 22:10, Chris Bono  >
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > I'm starting the vote for PIP-326, since it has been
> > reviewed
> > > > by
> > > > > > > > > > several members with no objections.
> > > > > > > > > >
> > > > > > > > > > PIP link: https://github.com/apache/pulsar/pull/21747
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > > Chris
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best regards,
> > > > > > Apurva Telang.
> > > > >
> > > >
> >
>


Re: [DISCUSS] Removing Pulsar-Trino plugin from main repo and call for volunteers to maintain it

2023-12-24 Thread guo jiwei
yes, +1 agree


Regards
Jiwei Guo (Tboy)


On Sat, Dec 23, 2023 at 11:37 AM Matteo Merli 
wrote:

> Good point. I have created a PR here:
> https://github.com/apache/pulsar/pull/21795
>
> We can always cherry-pick changes into the release branch, during the code
> freeze, with the appropriate precautions :)
>
> Matteo
>
>
> --
> Matteo Merli
> 
>
>
> On Fri, Dec 22, 2023 at 9:41 AM Lari Hotari  wrote:
>
> > Do we target release 3.2.0 if this change gets accepted?
> >
> > The code freeze for 3.2.0 was about to start today and I blocked that. I
> > removed the already started branch-3.2 (which didn't contain any changes)
> > until the decision has been made. I hope this makes sense. If not, we can
> > always cut the branch again, nothing has been lost.
> >
> > re: https://lists.apache.org/thread/0pl9by5c53nkjp7vld3x89c8nqjrx9on
> >
> > -Lari
> >
> > On 2023/12/22 17:09:19 Matteo Merli wrote:
> > > I want to start a discussion regarding the removal of all the code
> > related
> > > to the Trino (PrestoDB) plugin from the Pulsar main repository.
> > >
> > > This topic was already discussed and approved long time ago in PIP-62 (
> > >
> >
> https://github.com/apache/pulsar/wiki/PIP-62%3A-Move-connectors%2C-adapters-and-Pulsar-Presto-to-separate-repositories
> > > )
> > >
> > > The main reasons for not having Presto plugin as part of the main
> > > distribution of Pulsar were (and still are valid):
> > >
> > >  1. We need to ship the entire Presto runtime which is ~400 MB. This
> > makes
> > > our tgz and Docker images huge
> > >  3. There is no strict need for this component to be in the same
> > > distribution / image: it could easily be provided in a different
> release
> > > tgz or Docker image
> > >
> > > Though I think that since then it became more clear that the current
> > state
> > > of this plugin has been stagnating over the years.
> > >
> > > 1. There are not many active users of Pulsar-SQL component (I'd be very
> > > happy to be contradicted here)
> > > 2. The plugin code has not been improved in a long time
> > > 3. There are several open security issues (actually, almost the
> totality
> > of
> > > current dependencies issues are today coming from Trino).
> > >
> > > My suggestion would be that, if there is any volunteer willing to pick
> > this
> > > plugin up and maintain it in a separate repository (within the Apache
> > > Pulsar project) and with a separate release schedule, we should go
> ahead
> > > and move it.
> > > If there are no volunteers, we should just remove it as it is. If later
> > on
> > > we want to revive it, we can always import the code from the last
> commit.
> > >
> > > Thoughts?
> > >
> > >
> > > --
> > > Matteo Merli
> > > 
> > >
> >
>