Hi. > I think we do agree on most points: > > 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.] > > > > > Yes, smaller, "snap on" features are probably best addressed this way. The > issues with merging a feature branch into trunk are well known. The more > things a feature touches, the more merge conflicts present themselves. > However, in the context of monitoring iterative algorithms the merge should > be manageable. There are a lot of these types of minor to medium intensity > feature needs in math commons.
Yes, because the feature is new: It will probably mostly add code, not replace something existing which itself could evolve during the branch work... It was just a (maybe unnecessary) warning. > > > 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. > > > > Shame on the community in this case. If the community requests a feature and > you do the work for no reason, that's an indictment of the participants and > organizer. That's a risk that the developer always faces in these instances. To be fair, it was not a "community" request; it was a request from me. [See the discussion in the archives, if you are interested ;-).] Basically, my position was that CM should focus on math code; for _nothing_ else should it try to reinvent the wheel. In this instance this clashed with the current policy of not depending on external libraries. The same problem arises with logging. And with monitoring: If there would already exist a good (pure-Java) solution somewhere, it should be re-used, not re-implemented. > I don't quite see how that's argues against frequent feature branching. It was just an example of unnecessary work because the decision was made without regards to the branch code. It was a policy-based decision (no external library). > > 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. > > > > I think if we clean up the log jam that the discussions sometimes generate, > we can maximize the effectiveness of the human resources. > > As for the cost of branching, it is almost trivial. svn copy https://fromurl > https://tourl > > > > > 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 > > > > Who could argue against these points? I am only advancing the argument that > a branch allows for trying more new ideas. As for sticking to the old ways. > Not sure what you mean. Of course, I'm not trying to prevent you from working on a branch. I just said that I wouldn't recommend it myself. Also because it will require people to explicitly check out your branch and they might not do it in a timely fashion so that it might become so out of date that you'll have to do more work on it to keep in sync with the evolving trunk etc. This would not be a problem if "lazy consensus" were always working. As far as I'm concerned it did not work for redesigning the use of exceptions. Cf. the exception debate that goes on since issue MATH-195. [As an example of "sticking to old ways".] Regards, Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
