commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Commons - TLP
Date Fri, 19 Dec 2003 05:35:11 GMT
Quoting Henri Yandell <bayard@generationjava.com>:

> 
> 
> On Wed, 17 Dec 2003, __matthewHawthorne wrote:
> 
> > However, I'm not sure that I understand your suggestion about Jakarta
> > Commons becoming top level, and then being joined by Apache Commons.  I
> > think it should be the other way around -- Jakarta Commons projects
> > should become Apache Commons projects.
> 
> It's easier for 1 to join N, than for N to join 1. Rather than have us
> spend ages trying to modify A-C's rules until we feel like we like the
> idea, we can just suggest that we grandfather our rules in and invite the
> A-C people in to help us open our minds.
> 

Or just propose a Java-centric TLP that consists of the current jakarta-commons
and jakarta-commons-sandbox environments.  Being "joined" with A-C (in any
permutation) is not a necessary prerequisite to possible reorganizations.

> > But in a sense, it can all seem redundant.  If Apache Commons then has
> > projects for all languages, there would need to be at least a small
> > separation of projects by language, if only for web site listing, or
> > coding standards, etc.  So, there would be a Java branch of Apache
> > Commons -- which is kind of what Jakarta was in the first place,
> > Apache's Java project, right?
> 
> This starts getting us into big long email threads about how to architect
> a multi-language commons, and I'm not sure we need it yet. Even with a
> merger, there would only be 2 additional C projects so not enough to have
> a clue what the future will look like.
> 

Versus the fact that we already have ~25 packages, and an ecosystem that
supports independent development of small projects in a cooperative
environment.

> While we'll have to stop the project being java-centric, just to fit the
> components on the website and in the mind, we wouldn't have to find a new
> structure. So there wouldn't be a Java branch of Apache Commons, there
> would just be Apache Commons. It would be a bazaar of projects which might
> then choose the Java language as a categorisation, or might choose
> something else.
> 
> > So, my point is, I agree that Jakarta Commons might benefit in being
> > higher up.  I'm surprised that Struts isn't a top level project already,
> > but if it were to be, then that would be another top level project that
> > depends on JC -- which doesn't quite fit with the charter.
> >
> > Although, as I just mentioned, the language issues still confuse me.
> 
> And it should. I'm essentially proposing we deal with it later on when we
> have more data.

"Higher up" in terms of the legal organization (i.e. an Apache top level
project) has little or nothing to do with the marketing benefit of a brand name
like Jakarta, or the fact that most people use Google (not the Apache website)
to locate relevant packages.  And, if they want to use the Apache website, then
we have a (solvable) technical problem of how to organize what we have sorted
by various dimensions of interest (including, but certainly not limited to, the
implementation language).  The legal project organizational structure isn't (or
at least should not be) of much interest in such a search.

As it happens, the Struts community is likely to consider making a proposal for
TLP-hood in the short term.  But IMHO that's primarily because we've achieved
an ability to self govern that meets ASF requirements.  Successful execution of
such a change wouldn't really make any difference in the software that is
produced -- it would just mean that the committers doing all the work on Struts
would be the ones entitled to (and responsible for) the legalities as well as
the technical decisions.


> Hen

Craig


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


Mime
View raw message