On 6 October 2013 07:22, Christian Grobmeier <grobme...@gmail.com> wrote: > 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.
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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
