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 <dong...@apache.org> wrote: > > 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. > > - SPARK-15880: PREGEL Based Semi-Clustering Algorithm Implementation using > Spark GraphX API <https://issues.apache.org/jira/browse/SPARK-15880> > - SPARK-7244: Find vertex sequences satisfying predicates > <https://issues.apache.org/jira/browse/SPARK-7244> > - SPARK-7257: Find nearest neighbor satisfying predicate > <https://issues.apache.org/jira/browse/SPARK-7257> > - SPARK-8497: Graph Clique(Complete Connected Sub-graph) Discovery Algorithm > <https://issues.apache.org/jira/browse/SPARK-8497> > > Best, > Dongjin > > On Fri, Jan 20, 2017 at 2:48 AM, Michael Allman <mich...@videoamp.com > <mailto:mich...@videoamp.com>> wrote: > 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 because it > touches the ML codebase I'd like to get an ML committer to review that PR. > It's a relatively simple change and fixes an significant barrier to scaling > in GraphX. > > https://github.com/apache/spark/pull/15125 > <https://github.com/apache/spark/pull/15125> > > Cheers, > > Michael > > >> On Jan 19, 2017, at 8:09 AM, Takeshi Yamamuro <linguin....@gmail.com >> <mailto:linguin....@gmail.com>> wrote: >> >> 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/ <https://spark-packages.org/>)? ISTM >> graphx has already necessary and sufficient APIs for these third-party ones. >> >> On Thu, Jan 19, 2017 at 12:21 PM, Dongjin Lee <dong...@apache.org >> <mailto:dong...@apache.org>> wrote: >> 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 needed, I can take SPARK-10335 and SPARK-8497 after them. >> >> Thanks, >> Dongjin >> >> On Wed, Jan 18, 2017 at 2:40 AM, Sean Owen <so...@cloudera.com >> <mailto:so...@cloudera.com>> wrote: >> 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 <linguin....@gmail.com >> <mailto:linguin....@gmail.com>> wrote: >> 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 >> <http://spark.apache.org/contributing.html>) and >> I couldn't find any setting policy about "Later". >> So, IMO it's okay to set "Won't Fix" for now and those who'd like to make >> prs feel free to (re?-)open tickets. >> >> >> On Wed, Jan 18, 2017 at 1:48 AM, Dongjoon Hyun <dongj...@apache.org >> <mailto:dongj...@apache.org>> wrote: >> 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. >> >> --------------------------------------------------------------------- >> To unsubscribe e-mail: dev-unsubscr...@spark.apache.org >> <mailto:dev-unsubscr...@spark.apache.org> >> >> >> >> >> -- >> --- >> Takeshi Yamamuro >> >> >> >> -- >> Dongjin Lee >> >> Software developer in Line+. >> So interested in massive-scale machine learning. >> >> facebook: www.facebook.com/dongjin.lee.kr >> <http://www.facebook.com/dongjin.lee.kr> >> linkedin: kr.linkedin.com/in/dongjinleekr >> <http://kr.linkedin.com/in/dongjinleekr> >> github: <http://goog_969573159/>github.com/dongjinleekr >> <http://github.com/dongjinleekr> >> twitter: www.twitter.com/dongjinleekr <http://www.twitter.com/dongjinleekr> >> >> >> -- >> --- >> Takeshi Yamamuro > > > > > -- > Dongjin Lee > > Software developer in Line+. > So interested in massive-scale machine learning. > > facebook: www.facebook.com/dongjin.lee.kr > <http://www.facebook.com/dongjin.lee.kr> > linkedin: kr.linkedin.com/in/dongjinleekr > <http://kr.linkedin.com/in/dongjinleekr> > github: <http://goog_969573159/>github.com/dongjinleekr > <http://github.com/dongjinleekr> > twitter: www.twitter.com/dongjinleekr <http://www.twitter.com/dongjinleekr>
