I'm somewhat unclear - is the suggestion to submit projects to Apache Commons repositories or to do a similar process with our own multiple repositories.
On Tue, Nov 3, 2020 at 2:43 PM Gézapeti <[email protected]> wrote: > I'm not that close with Apache Commons either, but I think the > solr-operator is a perfect candidate to figure out how things should work. > I'd be happy to do some exploration and reach out to other projects about > their experience in this matter. > gp > > > On Tue, Nov 3, 2020 at 9:31 PM David Smiley <[email protected]> wrote: > >> 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 >>>> >>>
