commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Louis MONTEIRO <>
Subject Re: svn commit: r1528612 - /commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/
Date Sun, 06 Oct 2013 19:48:32 GMT
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."
Transmitting file data .
Committed revision 1529670.


2013/10/5 Christian Grobmeier <>

> On 5 Oct 2013, at 14:29, James Carman wrote:
>  On Sat, Oct 5, 2013 at 7:03 AM, Benedikt Ritter <>
>> 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.**<>
> For additional commands, e-mail:


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message