Deprecation doesn't stop any of that though, if you want to encourage people to do something with GraphX. We can un-deprecate things. We don't have to remove deprecated things.
But, why would we not encourage people to work on GraphFrames if interested in this domain? Nobody has been willing to come to the aid of GraphX in years and there is still no particular answer to why that would be different, as I take it you are not volunteering to work on it and don't have a use case here either. For those reasons, I don't believe this is motivated enough to sustain a veto. On Fri, Oct 4, 2024 at 7:16 PM Mark Hamstra <markhams...@gmail.com> wrote: > As I wrote to Holden privately, I might well change my vote to be in > favor of a deprecation label combined with some effective means of > communicating that this doesn't mean the end for GraphX if interested > contributors come forward to rescue it. I don't like either the idea > of keeping unmaintained code and public APIs around (especially if > there are problems with them) or the idea of removing Spark > functionality just because no one has contributed to it for a while. A > naked deprecation label feels somewhat drastic and pre-emptive to me. > I don't expect that GraphX will be the last part of Spark to run the > risk of death through neglect, and I think we need an effective means > of encouraging resuscitation that a deprecation label on its own does > not provide. On the other hand, if no one really is willing to come to > the aid of GraphX or other neglected functionality given adequate > warning of possible removal, I'm not then opposed to the usual > deprecation and removal process. > >
