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,
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
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
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.
-
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
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
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
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
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
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.
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
11 matches
Mail list logo