Hi folks!
The vote for 'SPIP: Single-pass Analyzer for Catalyst' passed with 14 +1s
(8 bindings, * = binding):
+1:
Reynold Xin (*)
Herman van Hovell (*)
Dongjoon Hyun (*)
Xiao Li (*)
Jungtaek Lim
Gengliang Wang (*)
John Zhuge
Yang Jie
Mridul Muralidharan (*)
Peter Toth
Wenchen Fan (*)
L. C. Hsieh
Hi,
Did anyone do any search about the GraphX API in Gitlab/Github and
different search engines to see if they are searched and actually used - or
we are considering it not used because the API wasn't changed?
Thanks!
Nimrod
On Mon, Sep 30, 2024 at 9:02 PM Holden Karau wrote:
> I think it has
FWIW, this is a Google Search trend in last 5 years:
[image: Screenshot 2024-10-04 at 6.54.42 PM.png]
I think it's fine to deprecate it
On Fri, 4 Oct 2024 at 18:40, Nimrod Ofek wrote:
> Hi,
>
> Did anyone do any search about the GraphX API in Gitlab/Github and
> different search engines to see
The graphframes library depends on GraphX and has changed recently (3
months ago).
https://github.com/graphframes/graphframes/blob/master/src/main/scala/org/graphframes/GraphFrame.scala
El vie, 4 oct 2024, 11:35, Nimrod Ofek escribió:
> Hi,
>
> Did anyone do any search about the GraphX API i
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
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 c
Personally, I would promote Best Practices given fair bit of opinions
either way.
- Share best practices for using GraphX effectively, including tips for
optimizing performance and avoiding common pitfalls.
- Encourage the use of alternative libraries when appropriate,
highlighting the
This is a reasonable discussion, but maybe the more practical point is: are
you sure you want to block this unilaterally? This effectively makes a
decision that GraphX cannot be removed for a long while. I'd understand it
more if we had an active maintainer and/or active user proposing to veto,
but
Looks like a missed a vote from Mich Talebzadeh
Updated list, 15 +1s (8 bindings, * = binding):
+1:
Reynold Xin (*)
Herman van Hovell (*)
Dongjoon Hyun (*)
Xiao Li (*)
Jungtaek Lim
Gengliang Wang (*)
John Zhuge
Yang Jie
Mridul Muralidharan (*)
Peter Toth
Wenchen Fan (*)
L. C. Hsieh (*)
Angel Alva
I completely agree with everyone here. I don’t think the issue is
deprecating it; to me, the problem lies in not providing a new and better
solution for handling graphs in Spark. In the past, I used GraphX via
GraphFrames for record linkage, and I found it both useful and effective.
Is there any di
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
-1(*) reasoning posted in the DISCUSS thread
On Mon, Sep 30, 2024 at 12:40 PM Holden Karau wrote:
>
> I think it has been de-facto deprecated, we haven’t updated it meaningfully
> in several years. I think removing the API would be excessive but deprecating
> it would give us the flexibility to
I'm -1(*) because, while it technically means "might be removed in the
future", I think developers and users are more prone to interpret
something being marked as deprecated as "very likely will be removed
in the future, so don't depend on this or waste your time contributing
to its further develop
Personally I think people should not depend on it — there’s literally no
one working on it, and not being up front about that I think draws
everything else into question.
Would anyone here feel comfortable using GraphX for a new production
deployment today?
Twitter: https://twitter.com/holdenkar
No, I wouldn't encourage anyone to base a new production deployment on
GraphX, but neither would I encourage new production deployments based
on the RDD API without deep study and understanding of the
implications and limitations. What I would be most comfortable with is
documenting the current sta
"You can't say nothing is removable until there are no users."
That is not what I am saying. Rather, I am countering what others seem
to be suggesting: There are no users and no interest, therefore we can
and should deprecate.
On Fri, Oct 4, 2024 at 3:10 PM Sean Owen wrote:
>
> I could flip this
Interesting, personally there are many use cases where I would recommend
RDDs — definitely to more advanced users — and I think that RDDs and GraphX
are in pretty different boats (RDDs are very actively used).
Twitter: https://twitter.com/holdenkarau
Fight Health Insurance: https://www.fighthealth
I could flip this argument around. More strongly, *not* being deprecated
means "won't be removed" and likewise implies support and development. I
don't think either of the latter have been true for years. What suggests
this will change? A todo list is not going to do anything, IMHO.
I'm also conce
18 matches
Mail list logo
