Hello. > 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.
For very-limited functionality, this could be an option. The big drawback is that, if it takes time to implement, the merge with the "official" branch may not be trivial. [IIUC, Ted suggested that "git" was superior to "svn" in making this less of a pain.] For functionality that encompasses a large part of the library, or a design change, or a policy change, it will be even more difficult, even if your proposal fits the initial bill as discussed on the ML. I've attempted one such experiment. You could search the archive for "cal10n". [Another project by Ceki Gulcu. Oops ;-).] I was asked to create a "sandbox" branch; I did all the proof-of-concept coding. In the end, nobody[1] checked out that branch for actual testing and the proposal was rejected because none of its merits could redeem the supposedly fundamental flaw of being (optionally) based on an external library (although that had been made very clear on the ML, also during a very long discussion). So, for me, never again! And I wouldn't dare advise it to anyone. Practically, given the low human resources (w.r.t the amount of code) in CM, I think that evolving the code together on a single branch is better. Nevertheless I totally agree with you, and I've said many times on this list, that * we should not expect to solve all problems in one ultimate design * we should release more often * we should not stick to old ways In my opinion, discussions should serve to solve real problems of a software library: bugs, design inconsistencies, efficiency improvements (in that order). Regards, Gilles [1] Please correct me if I'm wrong, and I apologize if so. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
