Then so will say no need to keep holding memory for this startup flag :p Monitoring will just go ahead and will surely be reworked a bit so no need to stop on details now JL Le 6 oct. 2013 21:49, "Jean-Louis MONTEIRO" <jeano...@gmail.com> a écrit :
> 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 >
