Re: GraphX-related "open" issues

2017-01-20 Thread Michael Allman
Yes, SPARK-10335 is a bug that will be fixed when SPARK-5484 is fixed. > On Jan 19, 2017, at 10:36 PM, Takeshi Yamamuro wrote: > > IMO SPARK-10335 should be tagged with "Bug"? If so, I think we should not > close it and fix in future. > > // maropu > > On Fri, Jan 20,

Re: GraphX-related "open" issues

2017-01-19 Thread Takeshi Yamamuro
IMO SPARK-10335 should be tagged with "Bug"? If so, I think we should not close it and fix in future. // maropu On Fri, Jan 20, 2017 at 1:27 PM, Michael Allman wrote: > That sounds fine to me. I think that in closing the issues, we should > mention that we're closing them

Re: GraphX-related "open" issues

2017-01-19 Thread Michael Allman
That sounds fine to me. I think that in closing the issues, we should mention that we're closing them because these algorithms can be implemented using the existing API. Michael > On Jan 19, 2017, at 5:34 PM, Dongjin Lee wrote: > > Thanks for your comments. Then, How

Re: GraphX-related "open" issues

2017-01-19 Thread Dongjin Lee
Thanks for your comments. Then, How about change following issues (see below) into 'won't fix'? After Implementing & uploading them as Spark Packages, commenting on those issues would be a reasonable solution. It would also be better for the potential users of those graph algorithms. -

Re: GraphX-related "open" issues

2017-01-19 Thread Michael Allman
Regarding new GraphX algorithms, I am in agreement with the idea of publishing algorithms which are implemented using the existing API as outside packages. Regarding SPARK-10335, we have a PR for SPARK-5484 which should address the problem described in that ticket. I've reviewed that PR, but

Re: GraphX-related "open" issues

2017-01-19 Thread Takeshi Yamamuro
Thanks for your comment, Dongjin! I have a pretty basic and also important question; why do you implement these features as a third-party library (and then upload them to the spark packages https://spark-packages.org/)? ISTM graphx has already necessary and sufficient APIs for these third-party

Re: GraphX-related "open" issues

2017-01-18 Thread Dongjin Lee
Hi all, I am currently working on SPARK-15880[^1] and also have some interest on SPARK-7244[^2] and SPARK-7257[^3]. In fact, SPARK-7244 and SPARK-7257 have some importance on graph analysis field. Could you make them an exception? Since I am working on graph analysis, I hope to take them. If

Re: GraphX-related "open" issues

2017-01-17 Thread Sean Owen
WontFix or Later is fine. There's not really any practical distinction. I figure that if something times out and is closed, it's very unlikely to be looked at again. Therefore marking it as something to do 'later' seemed less accurate. On Tue, Jan 17, 2017 at 5:30 PM Takeshi Yamamuro

Re: GraphX-related "open" issues

2017-01-17 Thread Takeshi Yamamuro
Thank for your comment! I'm just thinking I'll set "Won't Fix" though, "Later" is also okay. But, I re-checked "Contributing to JIRA Maintenance" in the contribution guide (http://spark.apache.org/contributing.html) and I couldn't find any setting policy about "Later". So, IMO it's okay to set

Re: GraphX-related "open" issues

2017-01-17 Thread Dongjoon Hyun
Hi, Takeshi. > So, IMO it seems okay to close tickets about "Improvement" and "New Feature" > for now. I'm just wondering about what kind of field value you want to fill in the `Resolution` field for those issues. Maybe, 'Later'? Or, 'Won't Fix'? Bests, Dongjoon.

GraphX-related "open" issues

2017-01-17 Thread Takeshi Yamamuro
Hi, devs Sorry to bother you, but plz let me check in advance; in JIRA, there are some open (and inactive) issues about GraphX features. IIUC the current GraphX features become almost freeze and they possibly get no modification except for critical bugs. So, IMO it seems okay to close tickets