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 <mich...@videoamp.com> wrote: > 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> > 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 >> >> Cheers, >> >> Michael >> >> >> On Jan 19, 2017, at 8:09 AM, Takeshi Yamamuro <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/)? 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> 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> 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> >>>> 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) 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> >>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> 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>* > > > -- --- Takeshi Yamamuro
