I'm not saying that deprecation necessarily precludes further contributions to the deprecated code. Without explicit and visible encouragement of further contributions, though, a deprecation label does actively discourage further contributions.
That, then, raises the question of whether we do want to actively discourage further development of GraphX. I don't have a strong opinion on that, and I could be persuaded that we do want to actively discourage (perhaps in favor of exclusive use of GraphFrames.) I'm not convinced, though, that a lack of recent contributions alone is sufficient reason to discourage further contributions to a neglected area of Spark in the way that a deprecation label devoid of caveats would. On Fri, Oct 4, 2024 at 5:27 PM Sean Owen <sro...@gmail.com> wrote: > > 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. >> --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
