No submitting subprojects to Apache Commons, just looking at their rules so the Apache Solr project can govern the subprojects in a similar matter. :)
On Tue, Nov 3, 2020 at 10:54 PM Mike Drob <[email protected]> wrote: > 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 >>>>> >>>>
