Thanks Gezapeti for recommending that model. It makes sense to me conceptually... yet it seems burdensome, at least to set it up (website, lists, repos, misc.) and get us familiar with a new way of working. I have nothing but questions about how they operate. As it is, we haven't even done our TLP split yet, which is maybe a little embarrassing as a PMC member. I wonder if other ASF projects do anything similar for their plugins? I'd guess Maven or Ant might be similar.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Wed, Oct 28, 2020 at 2:12 PM Gézapeti Cseh <[email protected]> wrote: > 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 >> >
