Hello. > [...] > >> > >> Another really important part is that CM doesn't have anymore a > >> hierarchy of exception. It has a bunch of completely unrelated > >> exceptions, all extending different standard Java exceptions. This is > >> the part that really bothers me, but this is the current consensus. > > > > I would be OK to change it to back to the previous state of affairs, that > > is, the one where we had agreed on a singly rooted hierarchy with base class > > "MathRuntimeException". > > The current consensus was reached because you didn't voice the concern you > > are now mentioning. > > I thought I had. Perhaps this feature was set up after I gave up on this > discussion.
Indeed. Phil wanted to have hierarchies that mirror the "java.lang" exceptions. As a CM developer, I preferred a singly rooted hierarchy (easier to understand and maintain), but as a CM user, I didn't care because whatever comes out of CM, I just wrap it in an application exception, and rethrow. > [...] > >> Too many rules are not a solution, especially when there are no tools to > >> help enforce these rules are obeyed. Relying only on the fact human > >> proof-reading will enforce them is wishful thinking. > >> > > > > What is "too many"? ["How long should a person's legs be?" ;-)] > > I don't agree with the "wishful thinking" statement; a "diff" could probably > > show a lot a manual corrections to the code and comment formatting. [Mainly > > in the sources which I touched at some point...] > > I'm not sure I understand your point. See below. > Mine is that rules that are not > backed by automated tools are a pain to enforce, and hence are not > fulfilled most of the time, except at a tremendous human resource cost. > In fact, even rules which can be associated with tools are broken during > development for some time. We do not use > checkstyle/CLIRR/findbugs/PMD/RAT for all commits for example, but do a > fix pass from time to time. Since I've learnt how to exclude report generators that take a long time to complete, I check checkstyle/CLIRR/findbugs findings at least every 2 or 3 commits. I'm not the only one, and that shows on the number of warnings which has been kept rather low since the release of 3.0. > > > > > There are other areas where there is only human control, namely the "svn > > log" messages where (no less picky) rules are enforced just because it > > helps _humans_ in their change overview task. My point was that I (as a human programmer) am able to quite easily detect inconsistent and/or sloppy code formatting. And it gets in the way of my trying to understand what the code is supposed to do. That's why, when I set on to try and find a problem in a piece of CM code, I first have to format it "properly". I am willing to spend some time reading new contributions and explaining in details what's wrong with the formatting and the code design, so that people can understand that the "pickiness" is not an excuse for rejecting them. > > > > As pointed out by Jared, it's not a big problem to comply with rules once > > you know them. > > I fully agree with that, but I also think Phil is right when he says too > many rules may discourage potential contributors. I remember a link he > sent to us months ago about to a presentation by Michael Meeks about > interacting with new developers > <http://people.gnome.org/~michael/data/2011-10-13-new-developers.pdf>. > Slides numers 3 an 4 are a fabulous example. I think we are lucky Jared > has this state of mind and accepts picky rules easily. I'm not sure such > an open mind is widespread among potential contributors. [The following is not a gratuitous _criticism_ of Jared's code; it happens to be a perfect example of my point in trying to help with long term maintainability of CM (in line with its, somewhere stated, goal referring to "state-of-the-art" Java library)...] Did you have a look at Jared's initial proposal? A "diff" between that code and the code actually committed shows that there can be a relatively large difference between source codes, just like there are big differences between the ways people write prose. Reworking his formatting and merging my suggestions, Jared even discovered (and corrected) a bug. The problem of not inisiting that people write "clean" contributions is the long-term maintainance, which lays with those developers who stay around and will have to dig into the code when someone reports a problem, possibly well after the contributor has disappeared... Slide 3 in the above document (which I had read at the time) is indeed very funny and interesting, but no one in his right mind should merge the equivalent patch to a FLOSS project. This would be shooting in one's foot. > > Keeping source code tidy is quite helpful, and potential contributors will > > be happy that they can read any CM source files and immediately recognize > > that they are part of the same library... > > Yes, of course. But the entry barrier should not be too high. But the _formatting_ barrier is _not_ high. Every programming project has rules so that contributors can, as I said, feel at home, in any source file. [That's not the case (for me) in several parts of CM.] The real barrier to contributing to CM is to be able to write numerical code. _That_ is not obvious; people who can do that should not be put off by a few rules. And it would be easier if those rules were laid out in a document (as I proposed, as Sébastien proposed, as Jared suggested, etc.). Regards, Gilles P.S. Among the recently most active CM developers, no one opposed any suggestions of code clean up. Jared's contribution was cleaned up while interacting on JIRA, without friction, I think. The opposition (to having rules enforced) argues about "potential" contributors who do not exist. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
