commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Grobmeier" <grobme...@gmail.com>
Subject Re: svn commit: r1528612 - /commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
Date Sat, 05 Oct 2013 20:22:58 GMT
On 5 Oct 2013, at 14:29, James Carman wrote:

> On Sat, Oct 5, 2013 at 7:03 AM, Benedikt Ritter <beneritter@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
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message