Hi all, Thanks for the discussion so far, but I would like to refocus on the problem at hand.
Our downstream users are asking for things that come at a cost to us as maintainers: An exception to our processes, better support for the final bridge release, and an easier maintenance burden. What is our consensus here? Should we disregard our users, and prioritize ourselves first? Thanks, Greg On Thu, Nov 21, 2024 at 12:52 PM Greg Harris <greg.har...@aiven.io> wrote: > Hi Ismael, > > Thanks for your responses. > > > At the same time, where do we draw the line when it > > comes to future unreleased Java versions? > > I don't think we need to make a determination on that at this time. We are > making a one-time judgement about backporting a specific patch to a > specific branch. We should have that discussion as a follow-up. > > > Is there evidence of this pain? That would help motivate the case. > > A downstream user has already replied to this thread, I'll relink it here > [1] and the issue they were working on [2]. > > > I don't think this is how we evaluate risk/reward, so I disagree with > your > > position here. > > Requiring users to set a system property is far from "harming" them. > > Nonetheless, if we can reduce friction, it's a good thing, > > I think you missed the point of my statement, which was that we can't > justify our behavior by hiding among other libraries. > If everyone did that, nobody would ever respond to deprecations. This is > an antisocial justification, I don't find it convincing, and we should not > rely on it. > > Thanks, > Greg > > [1] https://lists.apache.org/thread/312lm617q05k87kxsrwlqhk8rfg29t7g > [2] https://github.com/trinodb/trino/issues/23498 > > On Thu, Nov 21, 2024 at 12:16 PM Ismael Juma <m...@ismaeljuma.com> wrote: > >> Hi Greg, >> >> Comments below. >> >> On Thu, Nov 21, 2024 at 8:07 AM Greg Harris <greg.har...@aiven.io.invalid >> > >> wrote: >> >> > > Greg, why can't we set the relevant system property >> > > automatically for the broker/connect in 3.9.x? >> > >> > The System property workaround is not effective for Java 24 >> >> >> This is a fair point. At the same time, where do we draw the line when it >> comes to future unreleased Java versions? There are two possible paths: >> (1) >> we focus on the released versions, (2) we have a clear policy for future >> versions (the upcoming version, the upcoming LTS version, etc.). >> >> >> > and doesn't >> > cover the kafka-as-a-library use-case, which is the one which is >> generating >> > pain for our users. >> > >> >> Is there evidence of this pain? That would help motivate the case. >> >> >> > We already have a patch reviewed and merged which can fix this generally >> > (23/24, clients/streams/brokers/connect), and is low risk. Please review >> > the PR to convince yourself of this. >> > >> >> I did take a look at the PR and it did not seem low risk to me (it's >> larger >> than we'd typically consider for bug fix releases, it includes reflection, >> etc.). And hence why I was exploring other options. But it's not >> necessarily high risk either, it's somewhere in between. >> >> > When it comes to usage of >> > > Kafka as a library (eg clients), I very much doubt kafka will be the >> only >> > > system that requires this system property to be set, so not sure how >> much >> > > it matters. >> > >> > I don't think other libraries' support for SecurityManager is relevant >> to >> > this discussion, as there almost certainly is a downstream project out >> > there for which Kafka is the only dependency blocking their upgrade. >> > >> >> I don't think this is how we evaluate risk/reward, so I disagree with your >> position here. >> >> >> > And if all libraries took that strategy, that would harm the adoption of >> > Java 23 and users, so we should avoid implementing that strategy >> ourselves. >> >> >> Requiring users to set a system property is far from "harming" them. >> Nonetheless, if we can reduce friction, it's a good thing, >> >> Ismael >> >
