Hi.
On Thu, 9 Jun 2016 18:02:49 +0300, Artem Barger wrote:
On Thu, Jun 9, 2016 at 1:54 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
I guess someone need to prioritize them according to they
importance for
release.
Importance is relative... :-}
Indeed it's very objective function, however someone has to decide
where to focus.
Please list the alternatives, and I will let you know what are my
preferences.
But anyone can decide what he will do or not...
IMO, it is important to not release unsupported code.
So the priority would be higher for issues that would be included
in the release of the new Commons components.
Hence the need to figure out what these components will be.
Not clear whenever you really mean by not releasing unsupported code
is
to exclude already existing parts which doesn't anyone who will be
capable
to maintain the functionality and solve possible bugs?
I did not understand this sentence, sorry. :-}
Which ones?
I will look into JIRA and provide the issue numbers, and of
course I
can cover and assist with ML part and particular clustering.
Thanks.
You are welcome :)
So I looked through some of the open issues and I have a couple of
questions them:
1. Which affected version do I really need to consider as an
important to
be released in the next version?
It depends what is the contents of the release.
Certainly (IMO), issues in classes that are not going to be released
any
time soon, are low priority.
2. I've looked into affected versions: 3.5, 3.6, 3.6.1, 3.7 and 4.0.
Overall found
something like ~25 open bugs/issues. What about issues opened for
lower
releases?
Theses are probably the hardest to fix (often it relates to the
refactoring of whole packages like e.g. MATH-756).
As I've argued in this thread, my preference is to focus on extracting
independent functionalities and turn them into new components.
The point is not to about making negative choices (a.k.a. "dropping
code")
but making positive choices as to what you'd include in a given
component.
For example while I'm looking into MATH-1329
<https://issues.apache.org/jira/browse/MATH-1329>, it sounds not
really
hard to have it fixed,
but looking on it not sure whenever it was accepted and approved as
something that need
to be done.
Next MATH-1315 <https://issues.apache.org/jira/browse/MATH-1315>
seems like
reported has provided the patch and the only thing
missing is unit test, will addition of unit tests help to make that
one
resolved?
MATH-1284 <https://issues.apache.org/jira/browse/MATH-1284> here is
not
clear what is the final decision, according to comments look
like it can be resolved.
Here MATH-1262 <https://issues.apache.org/jira/browse/MATH-1262>
according
to the comments editing current javadoc to explain the limitation
should also rest this case, am I missing something?
I think I can help to handle MATH-1281
<https://issues.apache.org/jira/browse/MATH-1281>, right after I will
finish the refactoring and
optimizations for kmeans clustering.
[Please start a new thread for each of the specific issues above.
This list holds many conversations at the same time, and if multiple
subject are handled within a single thread, it quickly becomes
impossible to follow. Thanks!]
Listed issues/tickets where I can help to provide support or fix,
most
likely missed something
but can start with these.
It's up to you really which concrete issues you want to fix.
with additional functionality, since I think I can provide my code
for
several classification
algorithms.
That sounds nice.
Which algorithms?
Naive Bayes, kNN, Decision Trees, Random Forest. I guess adding
these into
the project will require
serious redesign of ML package.
Again, up to you to propose something new. :-)
IMHO, it is extremely important to have a clean design, and clear goals
(e.g. support for parallel computing).
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
