+1 (nb) for deprecation in 4.x and removal in 5.0

On 2023/03/09 18:04:27 Jeremy Hanna wrote:
> +1 from me to deprecate in 4.x and remove in 5.0.
> 
> > On Mar 9, 2023, at 12:01 PM, J. D. Jordan <jeremiah.jor...@gmail.com> wrote:
> > 
> > +1 from me to deprecate in 4.x and remove in 5.0.
> > 
> > -Jeremiah
> > 
> >> On Mar 9, 2023, at 11:53 AM, Brandon Williams <dri...@gmail.com> wrote:
> >> 
> >> I think if we reach consensus here that decides it. I too vote to
> >> deprecate in 4.1.x.  This means we would remove it in 5.0.
> >> 
> >> Kind Regards,
> >> Brandon
> >> 
> >>> On Thu, Mar 9, 2023 at 11:32 AM Ekaterina Dimitrova
> >>> <e.dimitr...@gmail.com> wrote:
> >>> 
> >>> Deprecation sounds good to me, but I am not completely sure in which 
> >>> version we can do it. If it is possible to add a deprecation warning in 
> >>> the 4.x series or at least 4.1.x - I vote for that.
> >>> 
> >>>> On Thu, 9 Mar 2023 at 12:14, Jacek Lewandowski 
> >>>> <lewandowski.ja...@gmail.com> wrote:
> >>>> 
> >>>> Is it possible to deprecate it in the 4.1.x patch release? :)
> >>>> 
> >>>> 
> >>>> - - -- --- ----- -------- -------------
> >>>> Jacek Lewandowski
> >>>> 
> >>>> 
> >>>> czw., 9 mar 2023 o 18:11 Brandon Williams <dri...@gmail.com> napisał(a):
> >>>>> 
> >>>>> This is my feeling too, but I think we should accomplish this by
> >>>>> deprecating it first.  I don't expect anything will change after the
> >>>>> deprecation period.
> >>>>> 
> >>>>> Kind Regards,
> >>>>> Brandon
> >>>>> 
> >>>>> On Thu, Mar 9, 2023 at 11:09 AM Jacek Lewandowski
> >>>>> <lewandowski.ja...@gmail.com> wrote:
> >>>>>> 
> >>>>>> I vote for removing it entirely.
> >>>>>> 
> >>>>>> thanks
> >>>>>> - - -- --- ----- -------- -------------
> >>>>>> Jacek Lewandowski
> >>>>>> 
> >>>>>> 
> >>>>>> czw., 9 mar 2023 o 18:07 Miklosovic, Stefan 
> >>>>>> <stefan.mikloso...@netapp.com> napisał(a):
> >>>>>>> 
> >>>>>>> Derek,
> >>>>>>> 
> >>>>>>> I have couple more points ... I do not think that extracting it to a 
> >>>>>>> separate repository is "win". That code is on Hadoop 1.0.3. We would 
> >>>>>>> be spending a lot of work on extracting it just to extract 10 years 
> >>>>>>> old code with occasional updates (in my humble opinion just to make 
> >>>>>>> it compilable again if the code around changes). What good is in 
> >>>>>>> that? We would have one more place to take care of ... Now we at 
> >>>>>>> least have it all in one place.
> >>>>>>> 
> >>>>>>> I believe we have four options:
> >>>>>>> 
> >>>>>>> 1) leave it there so it will be like this is for next years with 
> >>>>>>> questionable and diminishing usage
> >>>>>>> 2) update it to Hadoop 3.3 (I wonder who is going to do that)
> >>>>>>> 3) 2) and extract it to a separate repository but if we do 2) we can 
> >>>>>>> just leave it there
> >>>>>>> 4) remove it
> >>>>>>> 
> >>>>>>> ________________________________________
> >>>>>>> From: Derek Chen-Becker <de...@chen-becker.org>
> >>>>>>> Sent: Thursday, March 9, 2023 15:55
> >>>>>>> To: dev@cassandra.apache.org
> >>>>>>> Subject: Re: Role of Hadoop code in Cassandra 5.0
> >>>>>>> 
> >>>>>>> NetApp Security WARNING: This is an external email. Do not click 
> >>>>>>> links or open attachments unless you recognize the sender and know 
> >>>>>>> the content is safe.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 
> >>>>>>> I think the question isn't "Who ... is still using that?" but more 
> >>>>>>> "are we actually going to support it?" If we're on a version that old 
> >>>>>>> it would appear that we've basically abandoned it, although there do 
> >>>>>>> appear to have been refactoring (for other things) commits in the 
> >>>>>>> last couple of years. I would be in favor of removal from 5.0, but at 
> >>>>>>> the very least, could it be moved into a separate repo/package so 
> >>>>>>> that it's not pulling a relatively large dependency subtree from 
> >>>>>>> Hadoop into our main codebase?
> >>>>>>> 
> >>>>>>> Cheers,
> >>>>>>> 
> >>>>>>> Derek
> >>>>>>> 
> >>>>>>> On Thu, Mar 9, 2023 at 6:44 AM Miklosovic, Stefan 
> >>>>>>> <stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> 
> >>>>>>> wrote:
> >>>>>>> Hi list,
> >>>>>>> 
> >>>>>>> I stumbled upon Hadoop package again. I think there was some 
> >>>>>>> discussion about the relevancy of Hadoop code some time ago but I 
> >>>>>>> would like to ask this again.
> >>>>>>> 
> >>>>>>> Do you think Hadoop code (1) is still relevant in 5.0? Who in the 
> >>>>>>> industry is still using that?
> >>>>>>> 
> >>>>>>> We might drop a lot of code and some Hadoop dependencies too (3) 
> >>>>>>> (even their scope is "provided"). The version of Hadoop we build upon 
> >>>>>>> is 1.0.3 which was released 10 years ago. This code does not have any 
> >>>>>>> tests nor documentation on the website.
> >>>>>>> 
> >>>>>>> There seems to be issues like this (2) and it seems like the solution 
> >>>>>>> is to, basically, use Spark Cassandra connector instead which I would 
> >>>>>>> say is quite reasonable.
> >>>>>>> 
> >>>>>>> Regards
> >>>>>>> 
> >>>>>>> (1) 
> >>>>>>> https://github.com/apache/cassandra/tree/trunk/src/java/org/apache/cassandra/hadoop
> >>>>>>> (2) https://lists.apache.org/thread/jdy5hdc2l7l29h04dqol5ylroqos1y2p
> >>>>>>> (3) 
> >>>>>>> https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml#L507-L589
> >>>>>>> 
> >>>>>>> 
> >>>>>>> --
> >>>>>>> +---------------------------------------------------------------+
> >>>>>>> | Derek Chen-Becker                                             |
> >>>>>>> | GPG Key available at 
> >>>>>>> https://urldefense.com/v3/__https://keybase.io/dchenbecker__;!!PbtH5S7Ebw!YbHPCIGqxJHtAbvxPSXFEvnZgLrmvIE2AQ3Aw3BAgvCksv9ALniyHYVvU42wxrAGSNybhgjhwoAeyss$
> >>>>>>>   and       |
> >>>>>>> | 
> >>>>>>> https://urldefense.com/v3/__https://pgp.mit.edu/pks/lookup?search=derek*40chen-becker.org__;JQ!!PbtH5S7Ebw!YbHPCIGqxJHtAbvxPSXFEvnZgLrmvIE2AQ3Aw3BAgvCksv9ALniyHYVvU42wxrAGSNybhgjhfDqR0lc$
> >>>>>>>   |
> >>>>>>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
> >>>>>>> +---------------------------------------------------------------+
> >>>>>>> 
> 

Reply via email to