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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
