Hi, since we have discussed a lot of different aspects, it may be time to sum things up a bit (please correct me or add things I've missed):
Release Management - Releases take too long - Build is overly complex - dependencies to parent pom seem to be unclear - to few releases (more releases may attract more people) Technical/Coding Stuff - Commons feels legacy - Using old JDKs simply isn't fun - people are moving to alternative libs (for example guava) because commons feels like legacy code - switching to git (?!) Organisational Stuff - to few people work on to many components - Split up commons into several TLPs - Split up commons into bigger sub projects with individual MLs - decide what can be dormant and focus on core components Etiquette/Policies - we are a do-ocracy - discussions are started instead of fixing it yourself (specially in sandbox) - we don't have to be perfect (and we will never be ;-) - loosen API compatibility policy? I personally would like to at the point about commons public relations I've talked about a while back. Seriously: if you look at our website do you get the feeling that bleeding edge software is developed at commons? I intended to do something about the site but got caught up in the site build and then lost the motivation to dig deeper into the issue (which I'm a bit ashamed of, now that I've to spell it out loud ;-) The question is: how do we want to address these issues. I've seen endless discussions here with no result. That's another problem I see. When we get started with discussing, a lot of ideas come up, but little action is taken in the end. Benedikt 2013/10/7 James Carman <ja...@carmanconsulting.com> > On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <grobme...@gmail.com> > wrote: > > > > We discuss magic strings in the sandbox. Why? We don't need to discuss > that. > > Before we release we can simply check Sonar. Safe the time to discuss. > Fix > > it or leave it to Sonar to report it. > > > > +1! This sort of behavior definitely has to stop. It frustrates our > contributors. Nobody wants to get into lengthy discussions about this > level of minutiae. I know some folks have given up, because they > don't want to have to debate every little change they make. We vote > people in because they have the technical chops and have proven > themselves. They don't need a babysitter! Perhaps we should all > watch this video: > > http://www.youtube.com/watch?v=Q52kFL8zVoM > > Don't get me wrong, I am glad to know that we have people so dedicated > to the project that they are willing to monitor every single commit > message that comes through (I don't have that kind of time), but > perhaps that time would be better spent coding. If you see something > you think needs more documentation, then go document it. If you think > a refactoring is in order (like introducing a constant, extract > method, etc.), then go do it. Don't spend more of your time (and > theirs) writing up emails telling someone else to do it. Do it > yourself! > > For me, if you *have* to document your code, then you've failed. Your > code should be self-documenting. Comments eventually get out of sync > with the code and then you've got one big mess on your hands. Write > clear, elegant code and you don't have to worry about documentation. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
