Le 06/09/2011 14:29, Gilles Sadowski a écrit :
Hello.
Hi,
as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.
That's done already but might have been the object of another JIRA ticket,
as the changes did not depend on "RealVector".
The same thing should probably be done with solve(double[][]),
You could create a ticket for this already, to keep track of the tasks
that must be performed.
Gilles suggested we should probably wait and see what is going to
happen to the RealMatrix interface (creating views and all that) ===>
has a consensus been arrived at on this issue? This is a very exciting
topic, but I got the feeling that it meant: start again from zero.
The discussion seems to have quiet down; so starting the refactoring with
the removal of methods with primitive array argument is fine too, I think...
I haven't proceeded yet to clean FieldDecompositionSolver in the same
spirit. Should it be done?
That would seem logical.
But, let's wait for a confirmation.
Yes, these two classes hierarchies should be as similar as possible.
On a more general level, what's the policy in terms of closing a JIRA
ticket. I've looked on the website but could not find guidance. Who
takes the decision, on what grounds (question on the ML?).
If you mean "Close", I think that this is done only just before a release.
If you mean "Resolve", I guess that you can do it when the changes described
in the issue have been applied. If some additional changes (not formally
agreed on) were needed in the patch, I'd (usually) request agreement by
adding a comment to that effect, and if no objection is raised within a few
days, I'd set the issue as resolved. One can always reopen it afterwards if
necessary.
Yes. We set the issue as "Resolved" when a fix is available, and
"Closed" when it has been released.
Also, when
opening a new ticket, should it be assigned to someone, if this person
agrees to take care of it?
If you are willing to fix some issue, you should probably assign it to
yourself. That would help prevent duplicate work.
As far as I know, it's this other way round. When someone wants to solve
the issue, he assigned it to him directly, thus saying to other people
to not waste their time on it. We don't use it too often, but it helps
sharing the work.
Luc
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
