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. 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.] Best, Gilles
