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 > <mme...@apache.org> >
