Since there seems to be agreement here, I'll proceed with the PR for
removing the code.

If there are volunteers that are willing to continue maintaining the Trino
plugin, I'll be happy to help out in setting up the new repository and
import the existing code.

Thanks,
Matteo


--
Matteo Merli
<matteo.me...@gmail.com>


On Sun, Dec 24, 2023 at 7:47 PM Yubiao Feng
<yubiao.f...@streamnative.io.invalid> wrote:

> +1
>
> Thanks
> Yubiao Feng
>
> On Sat, Dec 23, 2023 at 1:09 AM Matteo Merli <mme...@apache.org> 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
> > <mme...@apache.org>
> >
>

Reply via email to