commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <>
Subject Re: Problems...
Date Sun, 05 Mar 2006 19:17:29 GMT
On 3/5/06, Henri Yandell <> wrote:
> On 3/4/06, Stephen Colebourne <> wrote:
> > Yes we have many, many problems.
> >
> > Site
> > Is this really our top priority? Is maven 2 helping here? Is maven 1? I
> Apart from thinking that our failure to work on an out of the box
> system is weak; my complaints are all on the site design. Will write
> stuff up on that - I've a long way to go before anyone is convinced by
> the sounds of it :)
> > Inactivity
> > Dormant has helped clarify the position. But are we willing to kick
> > [beanutils] and [dbcp] into dormant? Since all user requests and bugs
> > seem to have been ignored for many months, surely they are dormant? I
> > await the screams from the wider community...
> Inactivity is the number one issue

Is it really? Yes, there are one or two components that have a growing list
of open issues that aren't being addressed, but is inactivity really the
number one issue for Commons as a whole? Have we stepped back and taken a
look to see how many components are just "done" for the vast majority of
users? Sure, there will always be things that some people would like to see
added or changed, but is that our business? Taking on any change that any
one person wants to see?

Frankly, I think one of the things that's hurting Commons is excessive
navel-gazing. It's all the threads about how Commons (or Jakarta) is broken
that make me tired of being here. I might even spend some time on code if I
didn't have to spend it reading through all that mail...

Martin Cooper

, in the same way that breathing is
> the number one issue for any organism. We need to get the blood
> flowing; (nealry?) all of the other things mentioned are either to
> this end or to the same end for Jakarta.
> > Commons as the solution
> > We're not. We're barely holding our head above water.
> I'm definitely being chicken little and running around complaining
> about the sky falling; but my answer would be to look down at the
> drowned corpses below you :)
> Your answer does raise a very good point. My thinking has been that
> the various small components in Jakarta should fold into Commons -
> they're lost as subprojects. The larger subprojects would be split up,
> ie) velocity-core and velocity-dvsl would both be directly under
> Commons/Jakarta. However - this is under the huge assumption that this
> won't harm Commons.
> Option number 2 would be for Commons to goto TLP - and Jakarta could
> bury the corpses that don't twitch enough to keep their heads above
> water.
> > Leadership
> > Something Apache counsels against. Often however, the most successful
> > projects have a leader who drives the project forward and on occaisions
> > takes decisions. In commons we do have this, but only at the component
> > level. We feel unwilling, or are unable, or don't want, a cross commons
> > leader a lot of the time.
> There's a difference between a leader and Commons leading the way for
> Jakarta. Commons is talking about the issues that Jakarta is facing
> and not talking about. The answers Commons come up with will almost
> definitely be the answers Jakarta adopts. It's also proof for me on
> the Jakarta problem - it shoud be that "issues in Commons are not a
> Commons problem, they are a Jakarta problem - there is no Commons".
> Unless you mean me bringing this stuff up and throwing out insane
> ideas :) That's your own faults - you turned me into this hideously
> deformed middle-tier cat-herder and now I can't help it.
> > My analysis is that its time for a bit more radical surgery. And I mean
> > splitting commons into smaller communities. Jakarta Xxx Components sets
> > the naming pattern. If we do this, then each new group will be small
> > enough to be able to take decisions by itself, for example on the site.
> Agreed with Brett on my reply to him about this being Jakartazization.
> We can't go this way without radically new ideas on how to organize an
> umbrella.
> Hen
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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