Gilles, 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. > 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. I don't quite see how that's argues against frequent feature branching. 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. > 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 > > Overall, thank you. The comments were good. -Greg
