Hey guys, I don't want to interrupt such an interesting discussion. I just wanted to fix a typo I caught up.
If creating a constant with the right javadoc is ok, let's just do it, there is no big issue on that. Lemme me know if the following works. jlmonteiro$ svn ci -m "Adding a constant for the activation flag." reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java Sending reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java Transmitting file data . Committed revision 1529670. JLouis 2013/10/5 Christian Grobmeier <grobme...@gmail.com> > On 5 Oct 2013, at 14:29, James Carman wrote: > > On Sat, Oct 5, 2013 at 7:03 AM, Benedikt Ritter <benerit...@gmail.com> >> wrote: >> >>> >>> I'm not sure I agree with all of your points. Yes, the sandbox is a >>> place to try new ideas out. Does this mean certain quality criterions do >>> not apply? I don't think so. This all has to be corrected before promotion, >>> so why not make it correct right from the start? >>> >>> >> Sometimes it helps people to get their ideas down and working without >> worrying about "correctness." That's why writers have a rough draft, >> after all. The creative process is best left unencumbered when >> nurturing a new idea. The sandbox is all about letting folks work on >> an idea they have. It's a *sandbox*! Yes, it does mean that certain >> quality criteria do not apply, until the point when the component >> wishes to graduate to "proper." At that point, we can put on our >> white gloves and go over every last line (or look at Sonar reports) if >> we wish. >> >> Is pointing out that something may be improved nit-picking? Well, I >>> think it depends :-) Just sending a -1 for a commit like this would >>> definitely be. In this case an improvement has been pointed out. I'm more >>> then happy for feedback like this, because it helps me become a better >>> developer. And in the end, discussing commits is part of the game ;-) >>> >>> >> Yes, in a sandbox environment, pointing out a small "magic string" >> infraction is nit-picking. Leave the authors alone and let them work >> through their ideas. If you want to help out with the code, jump in >> and help. It takes longer to write an email and participate in the >> back-and-forth that ensues than it does to just fix it yourself. For >> issues like this, we really need to be using a tool like Sonar. Sonar >> will objectively look at the code for infractions such as this (among >> many others). The author can then look at the Sonar reports and see >> areas that might need improvement at their leisure (the group will >> also do so before graduating the component to proper). The other >> great thing about Sonar is that it has verbiage in there about why the >> rule is a rule and what can be done to fix the issue, so it's also a >> teaching tool. Most likely, the author fully understands why it's bad >> to have "magic strings" in their code, but just wanted to get their >> ideas into code and working before worrying about such issues. They >> can clean it up later (or some of us can jump in and help). >> >> This is the exact reason that I personally would *never* start a new >> project here at Commons again. I would invite certain colleagues to >> collaborate on github or something and then later bring the code into >> the organization. >> > > I am very sorry to say that I feel pretty similar. > > Commons is a lot on nit-picking. It once was an innovating place. > But often we discuss to many formalities or jdk 1.3 vs 1.5 vs 1.7 instead > of just making releases. Working at Commons is pretty much complicated. > It starts with a super complicated black magic parent pom and ends with > discussing > the value magic strings in the sandbox. > > I see your point Dominik. We need to discuss commits. But not at any time, > often not in the sandbox and not at any place. > > We are slow. Guava isn't slow. That's why more and more people walk over > to that place. > The way to long discussion on using annotation in Commons Collections is a > good example. > > Just want to say, the topic has changed. If anybody has the energy to > change the subject, it's the right time. > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Jean-Louis
