Hey, we even have historic tgz releases with both JAR files and source code, no need for git foo either :)
Jan > 12. nov. 2024 kl. 15:15 skrev Jason Gerlowski <gerlowsk...@gmail.com>: > > Yeah, no question that the code can be resurrected with some source > control magic. And it's in line with our backcompat requirements, as > long as hadoop-auth remains on branch_9x. But still - "dig the code > up yourself if you want it" might come off as a bit callous to > hadoop-auth users looking to upgrade to 10. > > Sounds like there's lots of folks against the idea though, so I accept > I'm the minority here. > > On Tue, Nov 12, 2024 at 8:58 AM David Smiley <dsmi...@apache.org> wrote: >> >> Thanks to source control history, it's always resurrectable by whomever >> cares enough to resurrect it. I don't think we should feel compelled to do >> anything more than remove it. If someone cares -- hey go for it. But I >> don't think we need a convention/process that includes this. >> >> On Tue, Nov 12, 2024 at 8:32 AM Jason Gerlowski <gerlowsk...@gmail.com> >> wrote: >> >>> Hey all, >>> >>> Apologies for chiming in to this a bit late. I don't have any >>> objection to the hadoop-auth module moving out of the apache/solr >>> repo, especially given the excellent due diligence you put in earlier >>> this year through your survey, in questions to users@ about usage, >>> etc. >>> >>> But should we have a plan for what happens to the code *after* that? >>> In other cases (e.g. DIH) we've created a repo containing the removed >>> code, so that anyone interested could still build it on their own. Is >>> that worth doing here? Is there any convention around where we do >>> that sort of thing, and where we skip it? >>> >>> Best, >>> >>> Jason >>> >>> On Wed, Nov 6, 2024 at 6:37 AM David Eric Pugh <de...@yahoo.com.invalid> >>> wrote: >>>> >>>> I wanted to share that I have a PR for removing only hadoop-auth module >>> here: https://github.com/apache/solr/pull/2835 >>>> On Tuesday, November 5, 2024 at 04:23:09 AM EST, Jan Høydahl < >>> jan....@cominvent.com> wrote: >>>> >>>> Can't you diff versions.lock betwen before and after to get a clue? In >>> case our validate-licenses gradle task does not complain about unused files >>> in licenses/ folder... >>>> >>>> Jan >>>> >>>>> 2. nov. 2024 kl. 12:27 skrev David Eric Pugh <de...@yahoo.com.INVALID >>>> : >>>>> >>>>> I did reach out to the user list about hadoop-auth and haven't heard >>> anything back. I may do another "bump" to see if I elicit anything. >>>>> >>>>> https://lists.apache.org/thread/vnd73j0nq3losfc17lzqp48g10r5tdgg >>>>> I am going to open up a JIRA and just see what's involved in removing >>> only the hadoop-auth module. >>>>> Anyone have tips on how I might figure out which licenses etc can be >>> removed when hadoop-auth is removed? A magic gradle command? >>>>> >>>>> >>>>> >>>>> On Monday, October 21, 2024 at 05:20:37 PM EDT, Gus Heck < >>> gus.h...@gmail.com> wrote: >>>>> >>>>> I was thinking about this recently too. I search our archives and the >>> only >>>>> interesting email regarding hadoop was a response in which Dave Smiley >>>>> pointed out that the backend is pluggable and thus it could be used to >>>>> target S3... but probably if we want to support an S3 storage backend, >>> this >>>>> should be done more directly and with a clear notion of how to avoid >>>>> wasting duplication on replicas when s3 already has its own >>> redundancy. (I >>>>> did see some mention of replicas creating needless redundancy on >>> hadoop). >>>>> There were a whole passel of CVE related emails that referenced CVE's >>> in >>>>> hadoop libs however. >>>>> >>>>> So I have seen little evidence that anyone uses this integration >>> anymore. >>>>> This probably however should be posed to the user list as well. >>>>> >>>>> If we can't drum up a response there, I'm definitely +1 to lightening >>> the >>>>> load via options 1 or 4. >>>>> >>>>> On Mon, Oct 21, 2024 at 5:05 PM David Eric Pugh >>> <de...@yahoo.com.invalid> >>>>> wrote: >>>>> >>>>>> I just re-read my copy of Marie Kondo's book The Life-Changing Magic >>> of >>>>>> Tidying Up[1] and it brought to mind the state of our Hadoop >>> integrations >>>>>> with Solr. I'd like to gauge the community's thoughts on how we move >>>>>> forward with Hadoop in Solr 10. >>>>>> My perspective is that Hadoop is no longer a key part of Solr's >>> future, >>>>>> and that is reflected in it's lack of maintenance and tech debt that >>> it >>>>>> appears to carrying. We seem to have a lot of points of discussion >>> where >>>>>> we want to do something and "but Hadoop doesn't support it" or "the >>> tests >>>>>> for Hadoop fail". >>>>>> >>>>>> I believe everything we would be removing is in:* Hadoop Auth Module* >>> HDFS >>>>>> Module >>>>>> >>>>>> If it's useful to the community I can make a longer argument about >>> why we >>>>>> need to thank Hadoop for it's service and say good bye. >>>>>> >>>>>> Otherwise, I think these are our paths forward: >>>>>> 1) Just straight up remove both modules in Solr 10 like we did with >>>>>> analytics. >>>>>> 2) Move both modules to the solr-sandbox repository. Can we just >>> leave >>>>>> them there on Solr 9 and see if they get some new life?3) Actively >>> recruit >>>>>> someone to be a committer focused on the Hadoop code to bring them up >>> to >>>>>> date and allow them to stay? I would want to time box this effort. >>>>>> 4) If someone volunteers to maintain them, move those modules to >>>>>> independent GitHub repos like we did with DIH. >>>>>> Thoughts? Other suggestions? >>>>>> >>>>>> Eric >>>>>> >>>>>> >>>>>> >>>>>> [1] https://en.wikipedia.org/wiki/Marie_Kondo >>>>>> >>>>>> >>>>> >>>>> -- >>>>> http://www.needhamsoftware.com (work) >>>>> https://a.co/d/b2sZLD9 (my fantasy fiction book) >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>>> For additional commands, e-mail: dev-h...@solr.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >>> For additional commands, e-mail: dev-h...@solr.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
