Hey everyone, Solr could keep some plugins with separate git repositories under the Apache umbrella if it adapts the Apache Commons model <http://commons.apache.org/>where plugins can have their own release schedule and community without the risk of being abandoned completely without notice. There is a process to get into Apache Commons via the sandbox <http://commons.apache.org/sandbox.html> and to end development in dormant <http://commons.apache.org/dormant.html>. I know this solution would still add the load of vulnerabilities and releases to the Apache Solr project, but components/plugins could have a level of separation while keeping the trust in ASF behind the plugins. Also, if a vulnerability surfaces for a particular plugin/component not the whole Solr release would be marked as affected. I'm not saying we should do this with DataImportHandler, but I think. it worth considering for other plugins.
I'm not sure if this was discussed before, I've tried to search the archives without any luck. gp On Thu, Oct 15, 2020 at 11:35 PM Anshum Gupta <[email protected]> wrote: > I think that the fact that this code is no longer under the Apache > umbrella will lead to such issues and moving this into a different GitHub > org wouldn't really help with the problem that's been highlighted. Also, > the maintainers of a plugin should be people who understand and monitor the > project and if those rights are opened up, it'd be hard to maintain > reliability of the plugin. > > Thanks for updating the Ref Guide, Cassandra :) In line with my suggestion > above, I think we need to be clear with the messaging of the fact that the > code no longer is owned and maintained by the Apache Lucene/Solr community > and any vulnerability or bug reported in the 3rd party packages wouldn't be > the responsibility of the Apache Lucene community. > > > On Thu, Oct 15, 2020 at 2:16 PM Cassandra Targett <[email protected]> > wrote: > >> I updated the Ref Guide for 8.7 to include a link to the plugin repo (for >> all plugins which have an established repo, not just DIH), hoping that >> would help answer user questions and spur adoption. That’s just a >> super-minor thing, but it’s something. >> >> If Rohit doesn’t have time to be a maintainer now and no one else wants >> to be, would a separate GitHub org help that? I understand the motivation >> for sharing the burden…I guess you’re thinking that single org would allow >> people to be maintainers on multiple plugins? >> >> Draft for 8.7 Guide is here if interested to see what I did: >> https://nightlies.apache.org/Lucene/Solr-reference-guide-8.x/uploading-structured-data-store-data-with-the-data-import-handler.html >> On Oct 15, 2020, 3:52 PM -0500, Jan Høydahl <[email protected]>, >> wrote: >> >> Some of those issues are opened by me, not beause I plan to be a DIH >> maintainer myself, but I was hoping that Rohit had some real interest in >> forming a comunity. >> Turns out that the plugin is as good as dead on arrival, which is really >> disappointing. >> >> We as the donator could perhaps help by sending an email, with a reminder >> that DIH is being deprecated and that the new plugin really needs more >> maintainers. >> That’s why I filed >> https://github.com/rohitbemax/dataimporthandler/issues/12, else people >> arriving to the page would not even know how to contribute or become a >> committer. >> I could whip up a PR for the README inviting contributors, but I’m >> honestly not so sure that newcomers would feel welcome, as their >> contributions would likely attract no attention :( >> >> So I wonder if instead someone (Ishan?) should setup a new GitHub >> organization, migrate the project there, and add Rohit and others as >> maintainers. That lifts the burden off one man's shoulders. >> >> Jan >> >> a15. okt. 2020 kl. 21:40 skrev Marcus Eagan <[email protected]>: >> >> There’s always issues opened in every product that aren’t being closed. >> Everyone who knows it or cares about it should be pitching in. >> >> Marcus >> >> On Thu, Oct 15, 2020 at 12:21 Eric Pugh <[email protected]> >> wrote: >> >>> I noticed that we’re getting tickets like SOLR-14938 opened that are >>> all about the future of DIH. I know some of my own clients are asking >>> about it as well. I suspect we will get more and more of these! >>> >>> I wonder if there are any ideas/suggestions on how to better communicate >>> that DIH isn’t going away, and indeed, it’s moving to a better place (I >>> hope!). Do we want to add to the UI a message about “join the new >>> community at https://github.com/rohitbemax/dataimporthandler”? >>> >>> Having said that, I see issues opening at >>> https://github.com/rohitbemax/dataimporthandler and not being closed, >>> so I do have some concerns that a supportive community may not actually be >>> forming. >>> >>> >>> Eric >>> >>> _______________________ >>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467 >>> | http://www.opensourceconnections.com | My Free/Busy >>> <http://tinyurl.com/eric-cal> >>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw> >>> This e-mail and all contents, including attachments, is considered to be >>> Company Confidential unless explicitly stated otherwise, regardless >>> of whether attachments are marked as such. >>> >>> -- >> Marcus Eagan >> >> >> > > -- > Anshum Gupta >
