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>*

Reply via email to