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 <anshum@anshumgupta.net>
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 <casstargett@gmail.com>
> 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 <jan.asf@cominvent.com>,
>> 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 <marcuseagan@gmail.com>:
>>
>> 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 <epugh@opensourceconnections.com>
>> 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
>