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

Reply via email to