commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <jcar...@carmanconsulting.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 12:29:14 GMT
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message