commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olivier Lamy <ol...@apache.org>
Subject Re: svn commit: r1528612 - /commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
Date Mon, 07 Oct 2013 00:59:50 GMT
On 6 October 2013 07:22, Christian Grobmeier <grobmeier@gmail.com> wrote:
> 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.

I cannot agree more....

>
> Just want to say, the topic has changed. If anybody has the energy to change
> the subject, it's the right time.
>

Will need to much energy and too many emails to write.
Most of the time all of those procedural minor stuff just kill motivation...


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



-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

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


Mime
View raw message