Hi Gilles,

Le 15/07/2011 16:57, Gilles Sadowski a écrit :
Hello.

Oops, this is indeed FORTRAN code in Java clothes. There is quite _a lot_ of 
work to make it look like Java... :(
Personally, I'd rather not commit it as is, because it is unmaintainable (it 
does not match anything in CM in terms of design and programming style).

Yes, but committing it this as is with an objective to "javaize" it
would allow to:

  - have a reference test harness to check changes do not introduce
    regressions
  - allow non-committer to help by providing small patches instead
    of always reworking the complete code (Dietmar is not a committer
    yet)
  - allow monitor what changes are introduced slightly
  - avoid delaying to much the availability of the feature so most
    people can test it
  - avoid delaying release to much as once the API is fixed (and in
    fact it depends on the optimization framework which is already
    defined), the implementation can be changed afterwards in 3.1

I agree the last point can lead to the code never been changed at
all, but the other points are important too.

The point of view of a maintainer will be that your last point will swamp
any other considerations.
It is not consistent that we "nit-pick" some small pieces of code while it
would be OK to commit that big scary one. [No offense to Dietmar, as this
was an important first step: It is really invaluable to be able to run the
tests as one is going through incremental changes.]

I'm willing to start adapting the code. If there are other candidates,
that's fine too. But I certainly do not want to spend time converting it
while somebody else is working on overlapping changes.

That's fine with me, I'll let you and Dietmar take care of this.


It is understandable that people would be happy to play with a new toy. But
they can also live without it (as they did until now) for some more time.
[Or they can patch their local copy.]

Yes, those who want to live on the bleeding edge are probably ready to put some effort in it.

best regards,
Luc



Best,
Gilles



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to