commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [DISCUSS] Mission Statement for Commons...
Date Mon, 07 Oct 2013 18:14:49 GMT
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 <james@carmanconsulting.com>

> On Sun, Oct 6, 2013 at 3:44 PM, Christian Grobmeier <grobmeier@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message