Yeah and the modules are very well self contained now, so even easier to just drip in from the old release. Who knows if itll work with the 10.x changes, like curator, though.
- Houston On Tue, Nov 12, 2024 at 8:51 AM Jan Høydahl <jan....@cominvent.com> wrote: > 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 > >
