I think you hit the nail on the head with the comment: "... but also the time to experiment. Only the latter will be able to tell if the design is good. And this must take time so that all the potential pitfalls can be ..."
Maybe this is chumming the water with more flotsam and jetsam, but a lot of the issues that arise in working out the best design ultimately revert to trying out a bunch of deadends [design by monte carlo ;)] The discussion on the list [from my rather limited history] seems to try to foresee all possible drawbacks with a design. This inevitably devolves into heated discussion and diminishing progress. Would it be possible to fork the trunk of the source tree to an "experimental branch"? Whether its monitoring the progress of ODE solvers, other solvers or any other feature extension, work could proceed on this experimental branch unmolested. There would be no concern about whether is this a 4.0 or 3.0 feature. The feature would be folded into trunk once it is ready (as evidenced by a vote of all concerned parties). Furthermore, all of us would have something very concrete to discuss. It would allow all interested parties to submit competing versions-instead of arguing over snippets of code. Phil has stressed to me that once an API change is made, that change is almost set in stone. An experimental branch would allow us to be more flexible and make mistakes without fear of supporting a garbage interface. -Greg It's not only the time to think, implement and test, but also the time to > experiment. Only the latter will be able to tell if the design is good. > And this must take time so that all the potential pitfalls can be > encountered... > > Also, for what it's worth, I'd prefer everyone to focus on the open issues > and advance towards 3.0. It's seemed that the thread which you started > about > a release plan was rather short-lived. Most unfortunately. > > > Regards, > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
