Good question, I guess that is part of what I hope to get out of this thread.
I was originally thinking: make the wording stronger in the docs as well as stopping CVE scans during release. But then I wonder about the optics of us providing artifacts in maven for things we are knowingly not scanning. Do we instead make users consciously opt into building these contrib extensions from source provided a handy guide from us on how to do it? This seems wildly inconvenient and would maybe smoke out disgruntled users who we can then kindly ask to take on maintainer work for them. If we go this route, do we still compile and test them as a part of our development process / CI, or just straight up hope they work for users when a release comes around? All in all I don't know that any answer is great here, but I'm hoping we can come to a compromise solution where the contrib extensions are still available to those who want to use them while not being a drag on the larger project. On Mon, Jul 14, 2025 at 5:13 PM Clint Wylie <cwy...@apache.org> wrote: > I think this sounds reasonable, but to clarify what would the actual > change be here, just stronger wording in > > https://druid.apache.org/docs/latest/configuration/extensions/#community-extensions > and not scanning for CVE? or something more, e.g. would we stop > publishing contrib jars to maven > (https://repo1.maven.org/maven2/org/apache/druid/extensions/contrib/)? > or stop compiling and running unit tests for these extensions? > > On Mon, Jul 14, 2025 at 6:23 AM Lucas Capistrant > <capistrant.lu...@gmail.com> wrote: > > > > Hi all, > > > > > > I’d like to open a discussion about the support model we apply to contrib > > extensions in Apache Druid. > > > > > > Specifically, I propose that we explicitly document that contrib > extensions > > are provided “as is”, meaning that the Druid PMC and committer community > > make no guarantees about their ongoing maintenance or compatibility. This > > would simply formalize what is already the de facto status today. > > > > > > We currently note that committers do not actively maintain contrib > > extensions. To clarify what this entails, we would make it clear that > > (among other things): > > > > > > - > > > > We do not commit to scanning for or resolving CVEs in contrib modules. > > - > > > > We do not guarantee compatibility of contrib extensions with future > > Druid versions or roadmap changes. > > > > > > This proposal reflects the current workload and priorities of the > committer > > base, which is heavily focused on maintaining and improving core Druid > and > > core extensions. While we deeply value the contributions of the community > > in creating new extensions, we want to set appropriate expectations about > > long-term support. Until a contrib extension has a dedicated maintainer > and > > meets the criteria to become a core extension, we cannot guarantee its > > upkeep. > > > > > > Of course, this does not prevent contributors from continuing to maintain > > or improve contrib extensions. It also does not preclude the possibility > of > > a contrib extension being promoted to core in the future. > > > > > > Looking forward to your thoughts. > > > > > > Thanks, > > > > Lucas Capistrant > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@druid.apache.org > For additional commands, e-mail: dev-h...@druid.apache.org > >
