You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@steitz.com> on 2003/12/23 02:00:02 UTC

[plea] get back to work -- was Re: [codec] [proposal] Moving To Apache Commons

Daniel F. Savarese wrote:
> In message <24...@atlanta.seagullsw.com>, Ga
> ry Gregory writes:
> 
>>Well, now I am switched around to a "-1" as well :-(
>>
>>
>>>From: Rodney Waldhoff 
>>>1) a-c organization: I think the organizational structure of
>>>apache-commons (one list per component, balkanized karma rights, etc.) is
>>>bad for those components technically and socially, and possibly bad
>>>for the ASF from an oversight perspective.
>>
>>I am not that familiar with a-c but I would prefer to keep all of the
>>Jakarta commons in one lump as much as possible. It is nicer to work and
>>explore in just one place, and perhaps offers more opportunity for
>>cross-pollination between components.
> 
> 
> I think something folks are missing is that if J-C moves to A-C, then
> all J-C committers become A-C PMC Members and can change the rules that
> don't make sense once A-C has incorporated J-C.  For example, and it's
> only a hypothetical for expository purposes and not a suggestion, we
> could create a jakarta@commons.apache.org list for components geared
> toward supporting Jakarta projects instead of using per component lists.

And what exactly would that buy us beyond what we have now in Jakarta Commons?

> ASF projects aren't implemented in a top-down fashion.  They evolve
> to meet changing needs.  The A-C organization will change accordingly

As mentioned repeatedly on this and other threads, there are many of us 
who view the Java-centric nature of Jakarta Commons as central to its 
definition and strength.  That does not make us language bigots or "bad 
Apache citizens."  It just means that we value the community that has 
grown around the Java components in Jakarta Commons and we would like to 
keep that community intact.

I find it ironic that this whole discussion is motivated in part by 
concern for oversight.  At least from a technical perspective, the 
oversight that the Jakarta Commons components get in this environment is 
much better than they would if j-c were broken up.  If we were to combine 
all of the Apache Commons projects (Jakarta, DB, XML, etc) together, the 
effectiveness of that community oversight would be much less, IMHO.  As a 
j-c committer and Jakarta PMC member, I view it as my responsibility to 
monitor commons-dev and commons-user carefully.  It would be *much* harder 
for me to do that in a generic commons environment.  The result would 
inevitably be segregation by technology or component type, which would 
lead to "Apache Commons" facing the same problems that "Apache Jakarta" is 
now.  For Jakarta Commons, the best that we could hope for is a period of 
uncertainty ending in more or less the same structure that we have now.

I agree with your statement in another post that none of this is likely 
going to be resolved without a vote.  Since I am not among the "dissolve 
Jakarta" camp, I am certainly not going to be the one to propose it; but I 
wish that we could put this subject to bed.  Either we dismantle Jakarta 
and force j-c to go TLP (preferred option, IMHO if necessary) or merge 
with Apache Commons, or we focus our efforts on moving Jakarta and j-c 
forward.

So here is my plea.  Either someone propose a [VOTE] to force all Jakarta 
components to merge with existing TLPs or become TLPs or we (Jakarta 
community) get back to work on fixing the following problems:

1. Signed CLAs from all committers
2. All active committers join the Jakarta PMC
3. Define oversight responsibilities for Jakarta PMC members in general 
and for j-c in particular, ensuring that we have sufficient oversight for 
each j-c component
4. Fix the j-c web site, agreeing with infrastructure@ on what needs to go 
in CVS (short term and long term) and when and how we "mavenize"
5. Get released versions out for all components that other Apache projects 
depend on
6. Update the j-c charter and release process docs to reflect current 
practices
7. Everything else that I forgot :-)

Phil





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


Re: [plea] get back to work -- was Re: [codec] [proposal] Moving To Apache Commons

Posted by Greg Stein <gs...@lyra.org>.
On Tue, Dec 23, 2003 at 09:18:43AM -0000, Stephen Colebourne wrote:
>...
> I'll say again - the Board could avoid this damage by
> choosing to ACT rather than REACT.

I don't think that I can stress this enough: the Board is too far removed
to "ACT" properly. We can certainly take actions, but it will invariably
be suboptimal.

The people who are supposed to act are the PMC. Without question.

If you think the Jakarta PMC cannot act to fix its problems, or problems
within J-C, then that is a whole different situation(*).

But the simple fact is that the Jakarta PMC should fix things, not the
Board. The Board is way too blunt, and is the wrong tool.

Cheers,
-g

(*) I tend to share your opinion that the PMC is too large and crosses too
many diverse communities to be able to reach any kind of consensus. My
response is TLPs. My hope is the PMC will recognize that well before the
Board is forced to take any action.

-- 
Greg Stein, http://www.lyra.org/

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


Re: [plea] get back to work -- was Re: [codec] [proposal] Moving To Apache Commons

Posted by Stephen Colebourne <sc...@btopenworld.com>.
I know exactly how you feel. The basic problem is that Jakarta, and
Jakarta-Commons, are now incapable of taking any decisions on contentious
issues. They are too large - too large for the discussion, too many mails,
too many personalities and and inability to hold a vote.

IMHO, the only hope is for individual products to choose to move to TLP
(lucene, slide and struts I'm hoping for). In effect, I'm hoping (praying)
that other products will then see the light and want to escape.

And then I suspect the final battle will commence - J-C vs Tomcat for the
Jakarta name. During this time, there will be little coding, much fustration
and community damage. I'll say again - the Board could avoid this damage by
choosing to ACT rather than REACT.

Stephen

----- Original Message -----
From: "Phil Steitz" <ph...@steitz.com>
> So here is my plea.  Either someone propose a [VOTE] to force all Jakarta
> components to merge with existing TLPs or become TLPs or we (Jakarta
> community) get back to work on fixing the following problems:
>
> 1. Signed CLAs from all committers
> 2. All active committers join the Jakarta PMC
> 3. Define oversight responsibilities for Jakarta PMC members in general
> and for j-c in particular, ensuring that we have sufficient oversight for
> each j-c component
> 4. Fix the j-c web site, agreeing with infrastructure@ on what needs to go
> in CVS (short term and long term) and when and how we "mavenize"
> 5. Get released versions out for all components that other Apache projects
> depend on
> 6. Update the j-c charter and release process docs to reflect current
> practices
> 7. Everything else that I forgot :-)
>
> Phil
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


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