> [...] > > Think about users reading the changelog, which is the source of the release > notes, or developers tracing the provencance or change history of code. > This, along with making it tractable for reviewers to review commits, is the > reason that we favor smaller, atomic commits and fully defined issues. I > know this takes time and some commits *have* to be large for atomicity; but > I think this one could have and should have been split up.
Most of the changes were proposed in this issue https://issues.apache.org/jira/browse/MATH-439 Given that its denomination was Refactoring of solvers (package "analysis.solvers") I thought that it was pretty clear that my interpretation of atomicity in this case was the package "analysis.solvers". IMHO, it is much clearer to have everything related changed at the same time. Moreover, I can then see that everything works together, instead of making several commits and then possibly having to undo things (and more commits) because they create problems further down. Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
