If someone wants this in 10x, they should not take it from branch_9x, they should take it from branch_10x (once it exists) at the point it was removed. It's been updated for Curator.
On Tue, Nov 12, 2024 at 11:02 AM Houston Putman <hous...@apache.org> wrote: > 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 > > > > >
