Communicating the future of DIH?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Communicating the future of DIH?

Eric Pugh-4
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  
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.

Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

Marcus Eagan
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 <[hidden email]> 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  
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

Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

Jan Høydahl / Cominvent
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 <[hidden email]>:

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 <[hidden email]> 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  
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


Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

David Smiley
In reply to this post by Eric Pugh-4
I'm glad you're raising this because I've been meaning get more visibility on a proposal I made in JIRA:
Pertinent part:
This is a great example of the problem because I'd rather we not log a warning about the DIH being deprecated – it is being moved. The deprecation notion is sometimes only useful for those maintaining Solr itself (us committers). Maybe we could just remove the annotation and only use the javadoc @deprecatedtag for plugins we know are moving?

Obviously this doesn't address most of Eric's point, but I think it would be helpful in avoiding undue concern amongst our users.  
Looking at https://cwiki.apache.org/confluence/display/SOLR/Deprecations it appears we're moving 3 plugins.  (1) DIH, (2) Velocity:  a javadoc @deprecated tag could be added to VelocityResponseWriter (currently doesn't have an annotations), and (3) HDFS: HdfsDirectoryFactory could get a @deprecated tag and remove the @Deprecated annotation.

Cool?

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Oct 15, 2020 at 3:21 PM Eric Pugh <[hidden email]> 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  
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.

Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

David Smiley
BTW I think a consultant/consuntancy would do good business in taking ownership of DIH.  Loads of people use it and some will come looking to pay for help!  Heck, even a user of my tiny HTTP Proxy Servlet https://github.com/mitre/HTTP-Proxy-Servlet/ inquired about paid support!  If I was still a freelancer, I think I would jump at this opportunity.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Oct 15, 2020 at 5:08 PM David Smiley <[hidden email]> wrote:
I'm glad you're raising this because I've been meaning get more visibility on a proposal I made in JIRA:
Pertinent part:
This is a great example of the problem because I'd rather we not log a warning about the DIH being deprecated – it is being moved. The deprecation notion is sometimes only useful for those maintaining Solr itself (us committers). Maybe we could just remove the annotation and only use the javadoc @deprecatedtag for plugins we know are moving?

Obviously this doesn't address most of Eric's point, but I think it would be helpful in avoiding undue concern amongst our users.  
Looking at https://cwiki.apache.org/confluence/display/SOLR/Deprecations it appears we're moving 3 plugins.  (1) DIH, (2) Velocity:  a javadoc @deprecated tag could be added to VelocityResponseWriter (currently doesn't have an annotations), and (3) HDFS: HdfsDirectoryFactory could get a @deprecated tag and remove the @Deprecated annotation.

Cool?

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Oct 15, 2020 at 3:21 PM Eric Pugh <[hidden email]> 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  
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.

Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

Cassandra Targett
In reply to this post by Jan Høydahl / Cominvent
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 <[hidden email]>, 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 <[hidden email]>:

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 <[hidden email]> 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  
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


Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

David Smiley
Thanks Cassandra.  I read it.  IMO, I think the word "Deprecated" is just too misleading for plugins that are *moving*.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Oct 15, 2020 at 5:16 PM Cassandra Targett <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]>:

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 <[hidden email]> 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  
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


Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

Anshum Gupta
In reply to this post by Cassandra Targett
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 <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]>:

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 <[hidden email]> 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  
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
Reply | Threaded
Open this post in threaded view
|

Re: Communicating the future of DIH?

Cassandra Targett
In reply to this post by David Smiley
Our messages crossed, but I read yours after I sent mine and I think I agree with you. I hear “deprecated” and think “it’s going away someday” but I keep getting questions from people (even inside Lucidworks) who are panicking like it’s gone in 8.6.3 already.

Speaking more generally, though, in some cases, though, we don’t know if it's moving - there is no maintainer yet. Until the repo exists and has some semblance of organization (a README, etc.), I think it’s very misleading to say something will exist somewhere else when it may not. HDFS is an example of this. The Deprecations page at https://cwiki.apache.org/confluence/display/SOLR/Deprecations says “Community package efforts underway”, but as far as I can see that’s just a link to a Jira issue where some discussion happened back in July. There is no repo at all yet. The plugin may or may not ever arrive.
On Oct 15, 2020, 4:23 PM -0500, David Smiley <[hidden email]>, wrote:
Thanks Cassandra.  I read it.  IMO, I think the word "Deprecated" is just too misleading for plugins that are *moving*.

~ David Smiley
Apache Lucene/Solr Search Developer


On Thu, Oct 15, 2020 at 5:16 PM Cassandra Targett <[hidden email]> 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 <[hidden email]>, 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 <[hidden email]>:

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 <[hidden email]> 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  
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