You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2003/12/17 23:59:55 UTC
Commons - TLP
[partially fantasy land/future ideas]
The Jakarta Commons charter basically views Commons as a supplier of
Jakarta projects, and not Apache projects in general.
With many of the Jakarta sub-projects moving to TLP status [ie)
ant.apache.org etc], this is increasingly untrue. Jelly's main customer
is Maven for example, quite a few XxxxUtils classes in Commons came from
Ant, and a lot of code came from a partial merger with Avalon's Excalibur.
There are two easy solutions [to think of]. The first is to change the
charter to match reality, ie) any ASF TLP is considered a client of
Jakarta Commons. The other is for Jakarta Commons to become a TLP.
I'd like to speak for the latter suggestion, I'd also then like to suggest
a more radical [flame-likely], though obvious next step.
Pluses I see for becoming a TLP:
* Currently we're viewed as a bit of an odd project in that we're an
umbrella project child of an umbrella project. Removing one of these
layers will improve the view that we have strong awareness of what's going
on and we would report directly to the board.
* It helps get us into the ASF community. We're a bit hidden away from new
TLP Java projects, such as the currently incubating Directory project, and
a TLP placement would lead to more involvement and a larger community
spread as new Java projects arrive there.
* There's community interest in a TLP Commons, and as a community we have
a large amount of knowledge we can bring to the table.
The last point suggests an obvious next step, which is some kind of
merging with the Apache Commons project. I would like to suggest that the
way we do this is that, J-C goes to TLP, with all its current rules and
community, A-C projects join J-C [currently just Serf, though a
*libtool project that's something to do with compiling C is likely to join
A-C too], J-C removes its Java-centric view and allows any language to
join.
The things I believe we should push for is that our current J-C group
should not try to de-java ourselves, but that we allow the A/J-C community
to choose its own delineations over time and not try and set them up to
begin with. Our mail lists would stay the same and they would join, and
over time we would decide, much like httpclient in the past, whether we
need new mail lists.
The PMC for such a thing would be based on all active committers, so no
real change than the current way in which the J-C bazaar is handled.
I think the ASF infrastructure group are going to want ASF projects to be
using subversion rather than cvs at some point in the future, and the
current A-C community has good subversion understanding with which to help
us if that should come to pass.
There are also obvious ties when similar domain products, serf/httpclient,
are able to communicate more openly and easily.
---
Does anyone have any negatives/positives of such a thing? Does it make any
sense for the future? Does it harm/help J-C?
Or am I just suggesting evil thoughts?
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
If that's the case, why not try to promote them to Jakarta proper? I
know little of jxpath, but Digester seems like it would fit under
Libraries, Tools, and APIs.
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net
__matthewHawthorne wrote:
> I think that Jakarta Commons is buried down deeper than it should be.
> Some of the projects such as [digester] and [jxpath] are so gosh darn
> useful that they deserve to be in a more visible space.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Scott Sanders <sc...@dotnot.org>.
Absolutely well stated.
+1
Scott
On Dec 20, 2003, at 10:00 AM, Ted Husted wrote:
> +1 for Matthew Harthrone's post.
>
> The board installed the Apache Commons with the charter "creation and
> maintenance of open-source software related to reusable libraries and
> components"
>
> <http://apache.org/foundation/records/minutes/2002/
> board_minutes_2002_09_18.txt>
>
> and it was later affirmed that the AC is language agnostic.
>
> IMHO, if we want to be good Apache citizens, then we should embrace
> the AC community. Many of our products could be made available in
> other languages, expanding on the idea of common components.
>
> Meanwhile, if more of us who joined the ASF through Jakarta are
> "rubbing elbows" with Apaches who entered through other projects, then
> there is a much better chance for Darwin to decide which aspects of
> the "Jakarta Way" and "Apache Way" should prevail.
>
> The very best place to do that would be an Apache Commons, where we
> can all serve together on a PMC with a clear and common goal.
>
> I would not oppose JC as a TLP, but in that case, we remain insular.
> If we join AC, then we take the first step toward creating a Unified
> Way.
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Scott Sanders <sc...@dotnot.org>.
I think that a lot of this can be taken care of in the join, should J-C
join A-C in its entirety, since there will be a large group joining a
smaller one.
On Dec 20, 2003, at 5:19 PM, Henri Yandell wrote:
>
> The big difference is that, if J-C joins A-C, we don't necessarily
> maintain our current release structures, rules, lists etc.
>
> If A-C joins J-C, the J-C way of doing things becomes the initial A-C
> way
> of doing things, and we fix the ones that are a problem for the new
> projects.
>
> A-C is 1 project currently, J-C is 30 odd. Changing 1 seems a lot
> easier
> than changing 30.
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Henri Yandell <ba...@generationjava.com>.
The big difference is that, if J-C joins A-C, we don't necessarily
maintain our current release structures, rules, lists etc.
If A-C joins J-C, the J-C way of doing things becomes the initial A-C way
of doing things, and we fix the ones that are a problem for the new
projects.
A-C is 1 project currently, J-C is 30 odd. Changing 1 seems a lot easier
than changing 30.
Hen
On Sat, 20 Dec 2003, Ted Husted wrote:
> +1 for Matthew Harthrone's post.
>
> The board installed the Apache Commons with the charter "creation and
> maintenance of open-source software related to reusable libraries and
> components"
>
> <http://apache.org/foundation/records/minutes/2002/board_minutes_2002_09_18.txt>
>
> and it was later affirmed that the AC is language agnostic.
>
> IMHO, if we want to be good Apache citizens, then we should embrace the
> AC community. Many of our products could be made available in other
> languages, expanding on the idea of common components.
>
> Meanwhile, if more of us who joined the ASF through Jakarta are "rubbing
> elbows" with Apaches who entered through other projects, then there is a
> much better chance for Darwin to decide which aspects of the "Jakarta
> Way" and "Apache Way" should prevail.
>
> The very best place to do that would be an Apache Commons, where we can
> all serve together on a PMC with a clear and common goal.
>
> I would not oppose JC as a TLP, but in that case, we remain insular. If
> we join AC, then we take the first step toward creating a Unified Way.
>
> -Ted.
>
> __matthewHawthorne wrote:
> > I'm fairly new to the Apache scene, but I think I like the idea. I
> > think that Jakarta Commons is buried down deeper than it should be. Some
> > of the projects such as [digester] and [jxpath] are so gosh darn useful
> > that they deserve to be in a more visible space.
> >
> > 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.
> >
> > 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 w
> > 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?
> >
> > 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.
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Commons - TLP
Posted by Ted Husted <hu...@apache.org>.
+1 for Matthew Harthrone's post.
The board installed the Apache Commons with the charter "creation and
maintenance of open-source software related to reusable libraries and
components"
<http://apache.org/foundation/records/minutes/2002/board_minutes_2002_09_18.txt>
and it was later affirmed that the AC is language agnostic.
IMHO, if we want to be good Apache citizens, then we should embrace the
AC community. Many of our products could be made available in other
languages, expanding on the idea of common components.
Meanwhile, if more of us who joined the ASF through Jakarta are "rubbing
elbows" with Apaches who entered through other projects, then there is a
much better chance for Darwin to decide which aspects of the "Jakarta
Way" and "Apache Way" should prevail.
The very best place to do that would be an Apache Commons, where we can
all serve together on a PMC with a clear and common goal.
I would not oppose JC as a TLP, but in that case, we remain insular. If
we join AC, then we take the first step toward creating a Unified Way.
-Ted.
__matthewHawthorne wrote:
> I'm fairly new to the Apache scene, but I think I like the idea. I
> think that Jakarta Commons is buried down deeper than it should be. Some
> of the projects such as [digester] and [jxpath] are so gosh darn useful
> that they deserve to be in a more visible space.
>
> 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.
>
> 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 w
> 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?
>
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Quoting Henri Yandell <ba...@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
Re: Commons - TLP
Posted by Henri Yandell <ba...@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.
> 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.
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.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Paul Libbrecht <pa...@activemath.org>.
Morgan Delagrange wrote:
> Hey all,
> I've been hesitant to join the holy war, but what the
> hell. By the way, for simplicity's sake I'll be
> referring to Jakarta Commons, past present and future,
> as a "project". Get over it. :)
I would be rather in favour of a top-level project.
I feel Jakarta Commons more tied to XML projects than to Jakarta
projects... (that's heavily subjective)
I don't think it's possible to hide java bias... so Apache Commons-J is
kind of needed... or ?
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
KUDOS! Very well put!
Morgan Delagrange wrote:
> Hey all,
>
> I've been hesitant to join the holy war, but what the
> hell. By the way, for simplicity's sake I'll be
> referring to Jakarta Commons, past present and future,
> as a "project". Get over it. :)
>
> Regarding promoting Jakarta Commons to a top level
> project...
> --------------------------------------------------
>
> I'm neither for nor against it. I'm satisfied with
> the visibility and activity of J-C today, but if there
> is sufficient interest in moving I would not be
> opposed. However, I believe some board members in
> past conversations have expressed that they would not
> support such a project, since they have already formed
> a top level "Commons" project and would not be
> interested in introducing another. For my part, I
> agree that it would be confusing to have another top
> level project, although maybe there's a way to make it
> work.
>
> Regarding moving components to Apache Commons...
> ------------------------------------------------
>
> The committers for a component can vote to join Apache
> Commons if they like. Personally, I still have
> reservations concerning A-C and at present would vote
> -1 on a move. I've expressed my views on many
> occasions, but I'll summarize some of the points here.
>
> 1. I'm not convinced that a language-specific project
> is a bad thing. For example look at the Commons
> charter:
>
> http://jakarta.apache.org/commons/charter.html
>
> It contains specific details about Java coding
> conventions, release formats, JDKs, JavaBeans, etc. I
> think that in a project which encourages small,
> well-constructed components, this level of detail is
> important. J-C had nearly all of these details
> committed to its Charter BEFORE it was approved by the
> Jakarta PMC. A-C has yet to scratch the surface.
>
> 2. I don't like their component karma policy.
>
> http://svn.apache.org/repos/asf/commons/STATUS
>
> Currently only Greg Stein has supported universal
> karma for all Apache Commons committers, like we have
> in Jakarta Commons. All the other PMC members support
> per-component karma (some with an unspecified and
> dubious-sounding "self-chosen aggregation"). Back
> when Apache Commons was first advocating a mass
> migration of Jakarta Commons components to Apache
> Commons, Peter Donald was advocating that the
> component developers could be more selective than the
> Apache Commons project itself and actually deny commit
> access to their component.
>
> I have joined several components simply because I saw
> something that needed fixing or thought of something
> useful. Raising the barriers of entry by requiring a
> vote or intervention by a CVS administrator is not
> reasonable to me. Existing veto procedures should be
> more than sufficient for the occasional rogue commit.
>
> 3. Apache Commons decision making seems too top-down.
> Only PMC members can make binding decisions concerning
> the makeup of the project. At J-C all along we have
> made our final decisions by majority vote, and the
> Jakarta PMC would only intervene if there were a legal
> issue or an unresolvable impasse (which IIRC has never
> occurred). When we were forming J-C we went to the
> main Jakarta mailing list and actively solicited
> volunteers to work out the details of the project, and
> from that point onward IMO it has been a group effort.
>
> In comparison Apache Commons had formed its PMC before
> most of us were aware of its existence, and certain
> decisions concerning karma, version control etc. have
> already been made by that small body. Things will
> probably loosen up in time, but I'd like to see some
> evidence that the project management will not be so
> heavy-handed before I would support a move.
>
> 4. I don't see sufficient benefit yet. If making
> Jakarta Commons a top-level project would be a lot of
> effort, merging with Apache Commons would be even more
> so. Converting our code (and our developers) to
> Subversion, creating separate karma for each
> component, hammering out all the detail which the
> Jakarta Commons charter already possesses, and for
> what? A top level domain? Who cares. Better
> oversight? I think we're doing fine. Synergy with C
> projects? That can be accomplished without ripping up
> track.
>
> In conclusion...
> ----------------
>
> Jakarta Commons is a 2 1/2 year old project which had
> (and still has) a lot of effort invested in it. I
> think it works well. If we were to become a top level
> project or merge with Apache Commons, I'd want to make
> sure that we ended up with a better arrangement, not
> one that is worse or merely different.
>
> - Morgan
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/commons
> http://axion.tigris.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://osprey.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Scott Sanders <sc...@dotnot.org>.
On Dec 18, 2003, at 2:08 PM, Greg Stein wrote:
> On Thu, Dec 18, 2003 at 12:17:05PM -0800, Morgan Delagrange wrote:
>> --- Henri Yandell <ba...@generationjava.com> wrote:
>>> Your view is very akin to mine I think.
>>>
>>> My suggested proposal is designed to basically get
>>> us to agree on the idea
>>> then we would propose to A-Commons that they join a
>>> TLP Jakarta Commons
>>> [with the name Apache Commons] and bootstrap the
>>> system with the Jakarta
>>> Commons system. Same avail as we have, same website,
>>> same rules etc.
>>
>> With some other details, like loosening the source
>> control requirements, it's a possibility if a) the
>> Apache-Commons PMC were to sign off on it,
>
> I believe that if the question were posed again to the A-C PMC, then
> you'd
> see *much* more agreement in the "commit access everywhere" model. As
> noted earlier, I'm a proponent of that model and have some pretty good
> arguments for it up my sleeve :-)
I was about to call you out on this one (from discussion on pmc@) :)
If this is the case, I am +1 for the merging of J-C and A-C into A-C.
I think the values that built J-C can help to grow A-C across
languages.
Scott Sanders
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Dec 18, 2003 at 12:17:05PM -0800, Morgan Delagrange wrote:
> --- Henri Yandell <ba...@generationjava.com> wrote:
> > Your view is very akin to mine I think.
> >
> > My suggested proposal is designed to basically get
> > us to agree on the idea
> > then we would propose to A-Commons that they join a
> > TLP Jakarta Commons
> > [with the name Apache Commons] and bootstrap the
> > system with the Jakarta
> > Commons system. Same avail as we have, same website,
> > same rules etc.
>
> With some other details, like loosening the source
> control requirements, it's a possibility if a) the
> Apache-Commons PMC were to sign off on it,
I believe that if the question were posed again to the A-C PMC, then you'd
see *much* more agreement in the "commit access everywhere" model. As
noted earlier, I'm a proponent of that model and have some pretty good
arguments for it up my sleeve :-)
If this was a precondition to be able to merge the various Commons
communities from across the ASF, then I fully expect the A-C PMC to switch
to that model.
Now: when I said A-C PMC above, please don't see it as the *existing* set
of people. See next point:
> and b) the
> PMC either adopted an immediate and aggressive policy
> of granting PMC status to committers
Justin, the current A-C Chair, actually posted to the list: if you want to
be on the PMC, then speak up. He has specifically set the bar "low" while
A-C gets bootstrapped.
There doesn't appear to be a web archive of the mailing list, but here is
the specific quote:
Okay, let's do this: If you're on this list (general@commons) and you
are already a committer to some other ASF commons project and would
like to help the ASF Commons by lending your insight and help us to
manage this endeavor, I'd like to solicit your self-nomination for
Commons PMC. Your stated interest in joining the PMC and prior
experience elsewhere within the ASF would be suitable justification
for me to nominate you to the rest of the PMC.
Note: this is a one-time offer. This isn't how things would normally
work, but we need to bootstrap ourselves by getting interested people
officially involved. -- justin
(I'm sure that "one-time" could be a "second-time" if we merge the various
Commons projects)
> or allowed the committers to vote on the big issues.
Only PMC Members can have binding votes. ASF rules, which are necessary
for proper oversight. The simple answer, of course, is to ensure that the
appropriate committers are on the PMC.
>...
> That's one of my main points. The Java-only
> references are important; it's sound advice that
> should be part of the project guidelines. "Remov[ing]
> Java only references" would be a mistake. That's my
> concern with a "language-agnostic" project: that
> important details would be glossed over (as they have
> been to-date) because they relate only to Java or C or
> whatever.
Seems you could have general guidelines, and language-specific guides. It
doesn't seem to be exclusive. Heck, I'd state that there would be
equivalent style (and other) guides for C, Perl, and Python.
> > As they have a lot of httpd background, I feel they
> > would help us a lot on
> > the formation of the initial PMC. They'll also be
> > useful for moving to
> > SVN, though I'd like to hear if the suggestions I've
> > seen that all of
> > Apache will use SVN are official or just bar-talk.
>
> I think it's premature to require SVN conversion until
> the tools catch up.
The ASF doesn't require anybody to use SVN, but in (say) a year or so, it
will. SVN provides a much higher level of code security (in terms of
protecting our repository from intrusion) than we have today with CVS.
At this point, the ASF is making SVN available, but isn't recommending any
transitions for projects. Sometime early next year, the ASF will make an
official request for projects to start thinking about the move. At some
point down the line, it will be required, as I mentioned.
The gentle rollout is to specifically deal with the case you mention:
ensure that the tools, procedures, utilities, etc have caught up.
> Until then, let the developers
> decide. And if it's not reasonable to maintain both
> an SVN and a CVS repository, then I say we use CVS for
> now, which most developers probably use both here and
> at their place of work.
Using both SVN and CVS within A-C would be entirely possible. Projects
would be encourage to move, but wouldn't have to. Note, however, that the
web site is in SVN, so the Commons committers would need to work with SVN
at some point.
>...
> That's your right under the voting rules. Under these
> circumstances, I wouldn't cast a vote on a component
> that I haven't committed code to, but I would support
> your option to vote against a component move. I think
> there are valid arguments either way, so your vote
> would definitely be valid.
I'm obviously not a member of this community, so I can't really speak for
what is Right(tm) for it or not, but I'd personally agree with Morgan.
> It's not reflected in their status document, but this
> is another significant point of divergence between A-C
> and J-C styles. When the topic was broached, IIRC the
> clear inclination amongst the A-C PMC was to restrict
> voting priveledges according to karma.
Yes, but I think we'd be getting rid of per-component karma barriers.
You're all-in, or not.
>...
Thanks for reading this far!
Cheers,
-g
p.s. most of this is my personal thinking. a few issues, such as voting
and SVN, come from my Director hat. for those who don't know, watch my
From: address. if I ever use @apache.org, then I'm definitely posting
officially. I skipped it here because the bulk is personal, and I didn't
want to add undue "weight" to those opinions.
--
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: Commons - TLP
Posted by Morgan Delagrange <md...@yahoo.com>.
--- Henri Yandell <ba...@generationjava.com> wrote:
>
> Your view is very akin to mine I think.
>
> My suggested proposal is designed to basically get
> us to agree on the idea
> then we would propose to A-Commons that they join a
> TLP Jakarta Commons
> [with the name Apache Commons] and bootstrap the
> system with the Jakarta
> Commons system. Same avail as we have, same website,
> same rules etc.
With some other details, like loosening the source
control requirements, it's a possibility if a) the
Apache-Commons PMC were to sign off on it, and b) the
PMC either adopted an immediate and aggressive policy
of granting PMC status to committers or allowed the
committers to vote on the big issues.
> We would de-java things to allow other languages in
> [ie) remove Java only
> references in charter, figure out website/cvs
> structure] but we would not
> embrace a feature-centric system and allow the Java
> community of 'ASF
> Commmons' to cling together if they wanted to.
That's one of my main points. The Java-only
references are important; it's sound advice that
should be part of the project guidelines. "Remov[ing]
Java only references" would be a mistake. That's my
concern with a "language-agnostic" project: that
important details would be glossed over (as they have
been to-date) because they relate only to Java or C or
whatever.
> As they have a lot of httpd background, I feel they
> would help us a lot on
> the formation of the initial PMC. They'll also be
> useful for moving to
> SVN, though I'd like to hear if the suggestions I've
> seen that all of
> Apache will use SVN are official or just bar-talk.
I think it's premature to require SVN conversion until
the tools catch up. Until then, let the developers
decide. And if it's not reasonable to maintain both
an SVN and a CVS repository, then I say we use CVS for
now, which most developers probably use both here and
at their place of work.
> I'm actually -1 to the idea that just the committers
> to one of our
> components can vote to move to A-C. The point of the
> Commons community I
> think is that we're all involved in one large
> codebase, with large
> striations, and that we'd all be a part of such a
> vote. Most of the time I
> would vote - or +0, but I think the whole Commons
> should vote.
That's your right under the voting rules. Under these
circumstances, I wouldn't cast a vote on a component
that I haven't committed code to, but I would support
your option to vote against a component move. I think
there are valid arguments either way, so your vote
would definitely be valid.
It's not reflected in their status document, but this
is another significant point of divergence between A-C
and J-C styles. When the topic was broached, IIRC the
clear inclination amongst the A-C PMC was to restrict
voting priveledges according to karma.
> Ditto on [sql] moving to DB Commons.
>
> We all vote on releases and adding new committers
> for example.
Yes absolutely.
> Hen
>
> On Thu, 18 Dec 2003, Morgan Delagrange wrote:
>
> > Hey all,
> >
> > I've been hesitant to join the holy war, but what
> the
> > hell. By the way, for simplicity's sake I'll be
> > referring to Jakarta Commons, past present and
> future,
> > as a "project". Get over it. :)
> >
> > Regarding promoting Jakarta Commons to a top level
> > project...
> > --------------------------------------------------
> >
> > I'm neither for nor against it. I'm satisfied
> with
> > the visibility and activity of J-C today, but if
> there
> > is sufficient interest in moving I would not be
> > opposed. However, I believe some board members in
> > past conversations have expressed that they would
> not
> > support such a project, since they have already
> formed
> > a top level "Commons" project and would not be
> > interested in introducing another. For my part, I
> > agree that it would be confusing to have another
> top
> > level project, although maybe there's a way to
> make it
> > work.
> >
> > Regarding moving components to Apache Commons...
> > ------------------------------------------------
> >
> > The committers for a component can vote to join
> Apache
> > Commons if they like. Personally, I still have
> > reservations concerning A-C and at present would
> vote
> > -1 on a move. I've expressed my views on many
> > occasions, but I'll summarize some of the points
> here.
> >
> > 1. I'm not convinced that a language-specific
> project
> > is a bad thing. For example look at the Commons
> > charter:
> >
> > http://jakarta.apache.org/commons/charter.html
> >
> > It contains specific details about Java coding
> > conventions, release formats, JDKs, JavaBeans,
> etc. I
> > think that in a project which encourages small,
> > well-constructed components, this level of detail
> is
> > important. J-C had nearly all of these details
> > committed to its Charter BEFORE it was approved by
> the
> > Jakarta PMC. A-C has yet to scratch the surface.
> >
> > 2. I don't like their component karma policy.
> >
> > http://svn.apache.org/repos/asf/commons/STATUS
> >
> > Currently only Greg Stein has supported universal
> > karma for all Apache Commons committers, like we
> have
> > in Jakarta Commons. All the other PMC members
> support
> > per-component karma (some with an unspecified and
> > dubious-sounding "self-chosen aggregation"). Back
> > when Apache Commons was first advocating a mass
> > migration of Jakarta Commons components to Apache
> > Commons, Peter Donald was advocating that the
> > component developers could be more selective than
> the
> > Apache Commons project itself and actually deny
> commit
> > access to their component.
> >
> > I have joined several components simply because I
> saw
> > something that needed fixing or thought of
> something
> > useful. Raising the barriers of entry by
> requiring a
> > vote or intervention by a CVS administrator is not
> > reasonable to me. Existing veto procedures should
> be
> > more than sufficient for the occasional rogue
> commit.
> >
> > 3. Apache Commons decision making seems too
> top-down.
> > Only PMC members can make binding decisions
> concerning
> > the makeup of the project. At J-C all along we
> have
> > made our final decisions by majority vote, and the
> > Jakarta PMC would only intervene if there were a
> legal
> > issue or an unresolvable impasse (which IIRC has
> never
> > occurred). When we were forming J-C we went to
> the
> > main Jakarta mailing list and actively solicited
> > volunteers to work out the details of the project,
> and
> > from that point onward IMO it has been a group
> effort.
> >
> > In comparison Apache Commons had formed its PMC
> before
> > most of us were aware of its existence, and
> certain
> > decisions concerning karma, version control etc.
> have
> > already been made by that small body. Things will
> > probably loosen up in time, but I'd like to see
> some
> > evidence that the project management will not be
> so
> > heavy-handed before I would support a move.
> >
> > 4. I don't see sufficient benefit yet. If making
> > Jakarta Commons a top-level project would be a lot
> of
> > effort, merging with Apache Commons would be even
> more
> > so. Converting our code (and our developers) to
> > Subversion, creating separate karma for each
> > component, hammering out all the detail which the
> > Jakarta Commons charter already possesses, and for
> > what? A top level domain? Who cares. Better
> > oversight? I think we're doing fine. Synergy
> with C
> > projects? That can be accomplished without
> ripping up
> > track.
> >
> > In conclusion...
> > ----------------
> >
> > Jakarta Commons is a 2 1/2 year old project which
> had
> > (and still has) a lot of effort invested in it. I
> > think it works well. If we were to become a top
> level
> > project or merge with Apache Commons, I'd want to
> make
> > sure that we ended up with a better arrangement,
> not
> > one that is worse or merely different.
> >
> > - Morgan
> >
> > =====
> > Morgan Delagrange
> > http://jakarta.apache.org/commons
> > http://axion.tigris.org
> >
> >
>
---------------------------------------------------------------------
> > 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
>
=====
Morgan Delagrange
http://jakarta.apache.org/commons
http://axion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Henri Yandell <ba...@generationjava.com>.
Your view is very akin to mine I think.
My suggested proposal is designed to basically get us to agree on the idea
then we would propose to A-Commons that they join a TLP Jakarta Commons
[with the name Apache Commons] and bootstrap the system with the Jakarta
Commons system. Same avail as we have, same website, same rules etc.
We would de-java things to allow other languages in [ie) remove Java only
references in charter, figure out website/cvs structure] but we would not
embrace a feature-centric system and allow the Java community of 'ASF
Commmons' to cling together if they wanted to.
As they have a lot of httpd background, I feel they would help us a lot on
the formation of the initial PMC. They'll also be useful for moving to
SVN, though I'd like to hear if the suggestions I've seen that all of
Apache will use SVN are official or just bar-talk.
I'm actually -1 to the idea that just the committers to one of our
components can vote to move to A-C. The point of the Commons community I
think is that we're all involved in one large codebase, with large
striations, and that we'd all be a part of such a vote. Most of the time I
would vote - or +0, but I think the whole Commons should vote.
Ditto on [sql] moving to DB Commons.
We all vote on releases and adding new committers for example.
Hen
On Thu, 18 Dec 2003, Morgan Delagrange wrote:
> Hey all,
>
> I've been hesitant to join the holy war, but what the
> hell. By the way, for simplicity's sake I'll be
> referring to Jakarta Commons, past present and future,
> as a "project". Get over it. :)
>
> Regarding promoting Jakarta Commons to a top level
> project...
> --------------------------------------------------
>
> I'm neither for nor against it. I'm satisfied with
> the visibility and activity of J-C today, but if there
> is sufficient interest in moving I would not be
> opposed. However, I believe some board members in
> past conversations have expressed that they would not
> support such a project, since they have already formed
> a top level "Commons" project and would not be
> interested in introducing another. For my part, I
> agree that it would be confusing to have another top
> level project, although maybe there's a way to make it
> work.
>
> Regarding moving components to Apache Commons...
> ------------------------------------------------
>
> The committers for a component can vote to join Apache
> Commons if they like. Personally, I still have
> reservations concerning A-C and at present would vote
> -1 on a move. I've expressed my views on many
> occasions, but I'll summarize some of the points here.
>
> 1. I'm not convinced that a language-specific project
> is a bad thing. For example look at the Commons
> charter:
>
> http://jakarta.apache.org/commons/charter.html
>
> It contains specific details about Java coding
> conventions, release formats, JDKs, JavaBeans, etc. I
> think that in a project which encourages small,
> well-constructed components, this level of detail is
> important. J-C had nearly all of these details
> committed to its Charter BEFORE it was approved by the
> Jakarta PMC. A-C has yet to scratch the surface.
>
> 2. I don't like their component karma policy.
>
> http://svn.apache.org/repos/asf/commons/STATUS
>
> Currently only Greg Stein has supported universal
> karma for all Apache Commons committers, like we have
> in Jakarta Commons. All the other PMC members support
> per-component karma (some with an unspecified and
> dubious-sounding "self-chosen aggregation"). Back
> when Apache Commons was first advocating a mass
> migration of Jakarta Commons components to Apache
> Commons, Peter Donald was advocating that the
> component developers could be more selective than the
> Apache Commons project itself and actually deny commit
> access to their component.
>
> I have joined several components simply because I saw
> something that needed fixing or thought of something
> useful. Raising the barriers of entry by requiring a
> vote or intervention by a CVS administrator is not
> reasonable to me. Existing veto procedures should be
> more than sufficient for the occasional rogue commit.
>
> 3. Apache Commons decision making seems too top-down.
> Only PMC members can make binding decisions concerning
> the makeup of the project. At J-C all along we have
> made our final decisions by majority vote, and the
> Jakarta PMC would only intervene if there were a legal
> issue or an unresolvable impasse (which IIRC has never
> occurred). When we were forming J-C we went to the
> main Jakarta mailing list and actively solicited
> volunteers to work out the details of the project, and
> from that point onward IMO it has been a group effort.
>
> In comparison Apache Commons had formed its PMC before
> most of us were aware of its existence, and certain
> decisions concerning karma, version control etc. have
> already been made by that small body. Things will
> probably loosen up in time, but I'd like to see some
> evidence that the project management will not be so
> heavy-handed before I would support a move.
>
> 4. I don't see sufficient benefit yet. If making
> Jakarta Commons a top-level project would be a lot of
> effort, merging with Apache Commons would be even more
> so. Converting our code (and our developers) to
> Subversion, creating separate karma for each
> component, hammering out all the detail which the
> Jakarta Commons charter already possesses, and for
> what? A top level domain? Who cares. Better
> oversight? I think we're doing fine. Synergy with C
> projects? That can be accomplished without ripping up
> track.
>
> In conclusion...
> ----------------
>
> Jakarta Commons is a 2 1/2 year old project which had
> (and still has) a lot of effort invested in it. I
> think it works well. If we were to become a top level
> project or merge with Apache Commons, I'd want to make
> sure that we ended up with a better arrangement, not
> one that is worse or merely different.
>
> - Morgan
>
> =====
> Morgan Delagrange
> http://jakarta.apache.org/commons
> http://axion.tigris.org
>
> ---------------------------------------------------------------------
> 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
Re: Commons - TLP
Posted by Morgan Delagrange <md...@yahoo.com>.
Hey all,
I've been hesitant to join the holy war, but what the
hell. By the way, for simplicity's sake I'll be
referring to Jakarta Commons, past present and future,
as a "project". Get over it. :)
Regarding promoting Jakarta Commons to a top level
project...
--------------------------------------------------
I'm neither for nor against it. I'm satisfied with
the visibility and activity of J-C today, but if there
is sufficient interest in moving I would not be
opposed. However, I believe some board members in
past conversations have expressed that they would not
support such a project, since they have already formed
a top level "Commons" project and would not be
interested in introducing another. For my part, I
agree that it would be confusing to have another top
level project, although maybe there's a way to make it
work.
Regarding moving components to Apache Commons...
------------------------------------------------
The committers for a component can vote to join Apache
Commons if they like. Personally, I still have
reservations concerning A-C and at present would vote
-1 on a move. I've expressed my views on many
occasions, but I'll summarize some of the points here.
1. I'm not convinced that a language-specific project
is a bad thing. For example look at the Commons
charter:
http://jakarta.apache.org/commons/charter.html
It contains specific details about Java coding
conventions, release formats, JDKs, JavaBeans, etc. I
think that in a project which encourages small,
well-constructed components, this level of detail is
important. J-C had nearly all of these details
committed to its Charter BEFORE it was approved by the
Jakarta PMC. A-C has yet to scratch the surface.
2. I don't like their component karma policy.
http://svn.apache.org/repos/asf/commons/STATUS
Currently only Greg Stein has supported universal
karma for all Apache Commons committers, like we have
in Jakarta Commons. All the other PMC members support
per-component karma (some with an unspecified and
dubious-sounding "self-chosen aggregation"). Back
when Apache Commons was first advocating a mass
migration of Jakarta Commons components to Apache
Commons, Peter Donald was advocating that the
component developers could be more selective than the
Apache Commons project itself and actually deny commit
access to their component.
I have joined several components simply because I saw
something that needed fixing or thought of something
useful. Raising the barriers of entry by requiring a
vote or intervention by a CVS administrator is not
reasonable to me. Existing veto procedures should be
more than sufficient for the occasional rogue commit.
3. Apache Commons decision making seems too top-down.
Only PMC members can make binding decisions concerning
the makeup of the project. At J-C all along we have
made our final decisions by majority vote, and the
Jakarta PMC would only intervene if there were a legal
issue or an unresolvable impasse (which IIRC has never
occurred). When we were forming J-C we went to the
main Jakarta mailing list and actively solicited
volunteers to work out the details of the project, and
from that point onward IMO it has been a group effort.
In comparison Apache Commons had formed its PMC before
most of us were aware of its existence, and certain
decisions concerning karma, version control etc. have
already been made by that small body. Things will
probably loosen up in time, but I'd like to see some
evidence that the project management will not be so
heavy-handed before I would support a move.
4. I don't see sufficient benefit yet. If making
Jakarta Commons a top-level project would be a lot of
effort, merging with Apache Commons would be even more
so. Converting our code (and our developers) to
Subversion, creating separate karma for each
component, hammering out all the detail which the
Jakarta Commons charter already possesses, and for
what? A top level domain? Who cares. Better
oversight? I think we're doing fine. Synergy with C
projects? That can be accomplished without ripping up
track.
In conclusion...
----------------
Jakarta Commons is a 2 1/2 year old project which had
(and still has) a lot of effort invested in it. I
think it works well. If we were to become a top level
project or merge with Apache Commons, I'd want to make
sure that we ended up with a better arrangement, not
one that is worse or merely different.
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/commons
http://axion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by __matthewHawthorne <ma...@phreaker.net>.
I'm fairly new to the Apache scene, but I think I like the idea. I
think that Jakarta Commons is buried down deeper than it should be.
Some of the projects such as [digester] and [jxpath] are so gosh darn
useful that they deserve to be in a more visible space.
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.
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?
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.
Henri Yandell wrote:
> [partially fantasy land/future ideas]
>
> The Jakarta Commons charter basically views Commons as a supplier of
> Jakarta projects, and not Apache projects in general.
>
> With many of the Jakarta sub-projects moving to TLP status [ie)
> ant.apache.org etc], this is increasingly untrue. Jelly's main customer
> is Maven for example, quite a few XxxxUtils classes in Commons came from
> Ant, and a lot of code came from a partial merger with Avalon's Excalibur.
>
> There are two easy solutions [to think of]. The first is to change the
> charter to match reality, ie) any ASF TLP is considered a client of
> Jakarta Commons. The other is for Jakarta Commons to become a TLP.
>
> I'd like to speak for the latter suggestion, I'd also then like to suggest
> a more radical [flame-likely], though obvious next step.
>
> Pluses I see for becoming a TLP:
>
> * Currently we're viewed as a bit of an odd project in that we're an
> umbrella project child of an umbrella project. Removing one of these
> layers will improve the view that we have strong awareness of what's going
> on and we would report directly to the board.
>
> * It helps get us into the ASF community. We're a bit hidden away from new
> TLP Java projects, such as the currently incubating Directory project, and
> a TLP placement would lead to more involvement and a larger community
> spread as new Java projects arrive there.
>
> * There's community interest in a TLP Commons, and as a community we have
> a large amount of knowledge we can bring to the table.
>
> The last point suggests an obvious next step, which is some kind of
> merging with the Apache Commons project. I would like to suggest that the
> way we do this is that, J-C goes to TLP, with all its current rules and
> community, A-C projects join J-C [currently just Serf, though a
> *libtool project that's something to do with compiling C is likely to join
> A-C too], J-C removes its Java-centric view and allows any language to
> join.
>
> The things I believe we should push for is that our current J-C group
> should not try to de-java ourselves, but that we allow the A/J-C community
> to choose its own delineations over time and not try and set them up to
> begin with. Our mail lists would stay the same and they would join, and
> over time we would decide, much like httpclient in the past, whether we
> need new mail lists.
>
> The PMC for such a thing would be based on all active committers, so no
> real change than the current way in which the J-C bazaar is handled.
>
> I think the ASF infrastructure group are going to want ASF projects to be
> using subversion rather than cvs at some point in the future, and the
> current A-C community has good subversion understanding with which to help
> us if that should come to pass.
>
> There are also obvious ties when similar domain products, serf/httpclient,
> are able to communicate more openly and easily.
>
> ---
>
> Does anyone have any negatives/positives of such a thing? Does it make any
> sense for the future? Does it harm/help J-C?
>
> Or am I just suggesting evil thoughts?
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 21, 2003, at 3:20 PM, Paul Libbrecht wrote:
>
>
> I might have overlooked something in the whole flood about this topic.
>
> Allow me to add that a move into Apache Commons might have our Java
> flavour sort of shaded. A move out of Jakarta Commons, however, might
> free our projects from the "server-only" orientation of Jakarta
> project in general.
Does anyone really keep that in mind ? I mean, anything can be used on
a server.
I think that we (the community) should address this in our charter as
soon as we get the bigger CLA and oversight issues squared away. If we
asked nicely, I'm sure that we could drop the 'server-only' aspect of
the charter.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Paul Libbrecht <pa...@activemath.org>.
I might have overlooked something in the whole flood about this topic.
Allow me to add that a move into Apache Commons might have our Java
flavour sort of shaded. A move out of Jakarta Commons, however, might
free our projects from the "server-only" orientation of Jakarta project
in general.
This orientation is stated somewhere in a charter I think. I remember
having it weaved at me everytime I was requesting that some component
of Jakarta Commons could be applet friendly.
I don't think any of jakarta-commons are actually server-only...
Paul
On 21-Dec-03, at 20:24 Uhr, Dirk Verbeeck wrote:
> The answer to the question "how would a Jakarta Commons TLP differ
> from an Apache Commons TLP?" is simple. The only difference would be
> that J-C does focus on java and A-C also includes other languages.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Dirk Verbeeck <di...@pandora.be>.
Hi Justin,
I'm sorry to say that this mail demonstrates there is still a
misunderstanding about how jakarta-commons works and its goals.
The answer to the question "how would a Jakarta Commons TLP differ
from an Apache Commons TLP?" is simple. The only difference would be
that J-C does focus on java and A-C also includes other languages.
J-C has demonstrated in the past that it can build community around
components from other ASF projects. Not only the original authors are
giving support but new comitters joined as well. Individual components
can have their own dedicated functional mailing lists if needed or can
graduate and move outside J-C like cactus did.
Personally I think all java components should stay together in J-C and
not some components here, some at A-C, DB-C or any other "java"
component commons look alike (sub)project.
You can ask the question why not move everything to A-C?
Let me answer with another question: Why should we?
I have followed most of the discussion on general@commons.apache.org
and cannot find a reason to move over. A functional split of the
mailing lists is a nice idea but also impractical. One list for each
programming language is easier.
While subversion is technically better, cvs is also easier. There are
of course tools for both but take a tomcat or struts committer. If
their commons component live in a subversion system then they need 2
sets of tools to build their projects. I don't know it maven and gump
are subversion ready but there are also the scripts people run to do
the nightly builds and other standard tasks.
When all of the ASF switches to subversion (and there is more native
tool support) then we will see the benefits but for the time being cvs
is good enough IMHO.
Same with the main A-C website, here at J-C we are moving toward a
maven build system for everything.
All these issues can be resolved of course. But the question remains:
Why should we invest time and energy in trying to fix something that
isn't broken?
Let us invest in handling some real improvements: merge to one wiki
system, switch to the new issue tracking system (JIRA), the repository
project for distributing binaries, dedicated integration/nightly build
system, automated website build system (forrest/maven-bot), website
backup strategy.
Of course maybe there are problems that I don't see, if so please
enlighten me.
This mail is already far too long but to come back to my previous
mail. I think we should make a clear distinction between groups formed
for legal reasons (oversight) == PMC, groups formed around a piece of
code (for example tomcat comitters), groups formed around the same
interests (for example: jakarta brand) and of course the whole Apache
group as a way of living ;-)
I have the impression that the oversight issue that started all of
this is growing into something threatening the community just because
we try to force everything into one structure while the real need is
for multiple structures. A legal one, interest groups and of course
groups for cultivating community/brands like jakarta. But that is
another personal opinion.
regards
Dirk
Justin Erenkrantz wrote:
> --On Saturday, December 20, 2003 4:20 PM +0100 Dirk Verbeeck
> <di...@pandora.be> wrote:
>
>> Maybe Jarkarta should take up the role of a Java@Apache gatekeeper.
>> Something like the java foundary at sourceforge but with the
>> additional task
>> to bring all the (independent) java communities together and provide a
>> vision for the Java@Apache future.
>
>
> For those of you that don't know me, hi, I'm currently Apache Commons
> PMC chair. Nothing I am saying here is binding as it's my personal
> opinion. As an ASF member, my only desire is for all ASF codebases to
> be given the opportunity to succeed - if it's in Apache Commons or not,
> that doesn't matter to me as long as the code has a chance to succeed
> within the ASF.
>
> One of the comments that I have seen in this thread is that J-C is a
> package deal - that J-C shouldn't be split up - all of the J-C projects
> should share the same fate. Please allow me to put forth some
> commentary on this.
>
> I believe one of the prime motivations for the ASF is that the people
> who are doing 'stuff' get a say in 'how' stuff is achieved
> (meritocracy). This is the main rationale behind the PMCs and TLPs -
> they should be composed of people who are actively contributing and
> providing direction and guidance to a project.
>
> However, an essential aspect of this guidance is motivated by the
> codebases involved. So, what direction and guidance can be provided by
> a Jakarta Commons TLP? The Apache Commons PMC has discussed how the
> Apache Commons can provide this direction and guidance at some length,
> so please let me provide our insights into this - perhaps it'll help
> frame your discussions. The question I'd like to keep in the back of
> your minds is how would a Jakarta Commons TLP differ from an Apache
> Commons TLP?
>
> Apache Commons has two desires: 1) build communities that can manage
> themselves around reusable codebases initially created *within* the ASF;
> 2) support smaller-scale projects that might not garner enough community
> interest to justify being a TLP but still worthy of the ASF's involvement.
>
> The Apache Commons PMC has maintained that when a community gets 'big'
> enough (or groupings of components can be composed as one TLP
> logically), we're going to ask the involved committers (who'll be on the
> Commons PMC) to form a new TLP and stand on its own. We believe there
> is no fundamental reason to keep projects that could manage themselves
> from doing so. There are several Apache Commons PMC members that have
> been involved in the formation of TLPs within the ASF and can help
> communities realize when it's time even though they themselves may not
> yet realize they are 'ready' as they haven't been involved in the
> creation of TLPs before.
>
> On the other hand, I honestly expect the fate of a fair number of the
> components in Apache Commons to be that they achieved their goal
> successfully. In this respect, Apache Commons would be very different
> than other TLPs which aren't supposed to have an easily attainable
> goal. There's only so many ways to write a regex library. Once it's
> done, there doesn't *have* to be much more work. So, the policies and
> procedures adopted by Apache Commons PMC is geared towards supporting a
> large number of reusable components and sharing between them. (This is
> one of the many reasons why Subversion was chosen for Apache Commons
> before the rest of the ASF switches to Subversion.)
>
> Now, what happens when projects leave a 'community' (i.e. a codebase
> becomes part of a TLP) - do they really leave? What's to stop people
> from being active in a number of different communities? I think you'll
> find that a lot of ASF members are involved in multiple open-source
> communities (both inside and outside of the ASF!). As you get involved
> with open-source projects, you'll find that you're going to run into a
> lot of familiar faces and then some not-so-familiar faces. I believe
> cross-pollination is wonderful.
>
>> From my outsiders' perspective, this cross-pollination is present to some
>
> extent here in Jakarta Commons already (yay!), but I think there's a
> reluctance to admit that this mailing list is really many different
> communities at work - every [subject] line group *is* a different
> community! There may be a lot of overlap between these communities and
> these communities may be small in size, but I believe each one should be
> able to direct itself according to their independent wishes.
>
> I know there's a lot of worry at the thought of partitioning J-C into
> codebases that may live in multiple TLPs or even in Apache Commons, but
> I'd just like to introduce some of the possible benefits and advantages
> of doing that. It may seem scary to many at first, but I think the end
> result is far stronger communities. Thanks! -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Tim O'Brien <to...@discursive.com>.
On Sun, 21 Dec 2003, Henri Yandell wrote:
>
> On Sun, 21 Dec 2003, Justin Erenkrantz wrote:
>
<snip...>
> When Configuration wants to declare itself ready for primetime, we all
> vote, when it wants to add a new committer, we all vote when this
> committer is from outside the ASF. When they're from inside the ASF we
> tend to get a bit confused :)
>
...and frequently, people propose new committers for codebases they
haven't been involved in.
...and *always* (except for maybe once) committerships pass with no -1
votes.
Tim
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Henri Yandell <ba...@generationjava.com>.
On Sun, 21 Dec 2003, Justin Erenkrantz wrote:
> One of the comments that I have seen in this thread is that J-C is a package
> deal - that J-C shouldn't be split up - all of the J-C projects should share
> the same fate. Please allow me to put forth some commentary on this.
Chief reason for my pushing this is that this is the way J-C does things.
When Validator 10.x is released, the whole group votes on it. Reality is
that only those who form a part of the active community vote, but it's
open for all.
When Configuration wants to declare itself ready for primetime, we all
vote, when it wants to add a new committer, we all vote when this
committer is from outside the ASF. When they're from inside the ASF we
tend to get a bit confused :)
> our insights into this - perhaps it'll help frame your discussions. The
> question I'd like to keep in the back of your minds is how would a Jakarta
> Commons TLP differ from an Apache Commons TLP?
There seem to be two differences so far. The first is in terms of the way
things are done. The bootstrap rules set in place for A-C do not fit how
J-C does things, but from what I understand this is not a huge problem as
A-C and J-C can both adapt when the time comes.
Language-centric is the other one. That's another reason for my proposal
of J-C as a whole to A-C. We maintain language-centric-ness and see if the
community wants to change over time.
> >From my outsiders' perspective, this cross-pollination is present to some
> extent here in Jakarta Commons already (yay!), but I think there's a
> reluctance to admit that this mailing list is really many different
> communities at work - every [subject] line group *is* a different community!
It may appear that way, but I think there are actually two major
communities in Commons and a few others who are their own.
Children-of-Struts and Children-of-Utils are the two large communities, in
that the overlap between those components are high. Other things like
httpclient and jelly are more stand-alone and have less overlap.
Still, you're mostly correct with respect to lots of individual
communities.
> There may be a lot of overlap between these communities and these communities
> may be small in size, but I believe each one should be able to direct itself
> according to their independent wishes.
>
> I know there's a lot of worry at the thought of partitioning J-C into
> codebases that may live in multiple TLPs or even in Apache Commons, but I'd
> just like to introduce some of the possible benefits and advantages of doing
> that. It may seem scary to many at first, but I think the end result is far
> stronger communities.
More mail lists to listen to! ;)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Saturday, December 20, 2003 4:20 PM +0100 Dirk Verbeeck
<di...@pandora.be> wrote:
> Maybe Jarkarta should take up the role of a Java@Apache gatekeeper.
> Something like the java foundary at sourceforge but with the additional task
> to bring all the (independent) java communities together and provide a
> vision for the Java@Apache future.
For those of you that don't know me, hi, I'm currently Apache Commons PMC
chair. Nothing I am saying here is binding as it's my personal opinion. As
an ASF member, my only desire is for all ASF codebases to be given the
opportunity to succeed - if it's in Apache Commons or not, that doesn't matter
to me as long as the code has a chance to succeed within the ASF.
One of the comments that I have seen in this thread is that J-C is a package
deal - that J-C shouldn't be split up - all of the J-C projects should share
the same fate. Please allow me to put forth some commentary on this.
I believe one of the prime motivations for the ASF is that the people who are
doing 'stuff' get a say in 'how' stuff is achieved (meritocracy). This is the
main rationale behind the PMCs and TLPs - they should be composed of people
who are actively contributing and providing direction and guidance to a
project.
However, an essential aspect of this guidance is motivated by the codebases
involved. So, what direction and guidance can be provided by a Jakarta
Commons TLP? The Apache Commons PMC has discussed how the Apache Commons can
provide this direction and guidance at some length, so please let me provide
our insights into this - perhaps it'll help frame your discussions. The
question I'd like to keep in the back of your minds is how would a Jakarta
Commons TLP differ from an Apache Commons TLP?
Apache Commons has two desires: 1) build communities that can manage
themselves around reusable codebases initially created *within* the ASF; 2)
support smaller-scale projects that might not garner enough community interest
to justify being a TLP but still worthy of the ASF's involvement.
The Apache Commons PMC has maintained that when a community gets 'big' enough
(or groupings of components can be composed as one TLP logically), we're going
to ask the involved committers (who'll be on the Commons PMC) to form a new
TLP and stand on its own. We believe there is no fundamental reason to keep
projects that could manage themselves from doing so. There are several Apache
Commons PMC members that have been involved in the formation of TLPs within
the ASF and can help communities realize when it's time even though they
themselves may not yet realize they are 'ready' as they haven't been involved
in the creation of TLPs before.
On the other hand, I honestly expect the fate of a fair number of the
components in Apache Commons to be that they achieved their goal successfully.
In this respect, Apache Commons would be very different than other TLPs which
aren't supposed to have an easily attainable goal. There's only so many ways
to write a regex library. Once it's done, there doesn't *have* to be much
more work. So, the policies and procedures adopted by Apache Commons PMC is
geared towards supporting a large number of reusable components and sharing
between them. (This is one of the many reasons why Subversion was chosen for
Apache Commons before the rest of the ASF switches to Subversion.)
Now, what happens when projects leave a 'community' (i.e. a codebase becomes
part of a TLP) - do they really leave? What's to stop people from being
active in a number of different communities? I think you'll find that a lot
of ASF members are involved in multiple open-source communities (both inside
and outside of the ASF!). As you get involved with open-source projects,
you'll find that you're going to run into a lot of familiar faces and then
some not-so-familiar faces. I believe cross-pollination is wonderful.
>>From my outsiders' perspective, this cross-pollination is present to some
extent here in Jakarta Commons already (yay!), but I think there's a
reluctance to admit that this mailing list is really many different
communities at work - every [subject] line group *is* a different community!
There may be a lot of overlap between these communities and these communities
may be small in size, but I believe each one should be able to direct itself
according to their independent wishes.
I know there's a lot of worry at the thought of partitioning J-C into
codebases that may live in multiple TLPs or even in Apache Commons, but I'd
just like to introduce some of the possible benefits and advantages of doing
that. It may seem scary to many at first, but I think the end result is far
stronger communities. Thanks! -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Henri Yandell <ba...@generationjava.com>.
That's one long term vision for Jakarta, and I think the best one.
The other one that seems to have strength is a focus on Tomcat as a
web-container and associated projects.
To this end, I can see Jakarta Commons going to TLP and trying to take
BCEL, BSF, ORO and Regexp with it. Gump would go its own way to TLP-ness.
In my fantasy world information architecture.
The latter fantasy means a lack of a java@apache place, with J-C being
more of a workshop for small focused pieces.
Hen
On Sat, 20 Dec 2003, Dirk Verbeeck wrote:
> Maybe Jarkarta should take up the role of a Java@Apache gatekeeper.
> Something like the java foundary at sourceforge but with the
> additional task to bring all the (independent) java communities
> together and provide a vision for the Java@Apache future.
>
> -- Dirk
>
>
> Henri Yandell wrote:
>
> > The Jakarta brand may be interpreted to be: "web-based server-side code".
> > It's definitely not Java@Apache anymore.
> >
> > It's only Java@Apache in the same way that people thought Jakarta==Tomcat
> > and Jakarta was separate from ASF.
> >
> > Xerces is a very good example of a group who could happily be gaining from
> > the a same-function mailing list, and yet their community has chosen not
> > to share one mailing list [I assume]. So a good argument for us to use
> > for some language separation between Commons'es.
> >
> > Hen
> >
> > On Fri, 19 Dec 2003, Dirk Verbeeck wrote:
> >
> >
> >>I agree with the statement that the Jakarta Commons charter needs an
> >>update and there is also nothing against becoming a TLP and reporting
> >>directly to the board.
> >>
> >>But we should keep the Jakarta brand. Jakarta as the main java entry
> >>point at Apache and as a provider for the java news/download is
> >>important I think. (see also general@jakarta)
> >>
> >>I think a lot of people think "Jakarta" when you ask for java from
> >>apache. The jakarta-commons is then a logical place for all reusable
> >>java components. (and yes I think the java components in db-commons
> >>would benefit from moving to jakarta-commons)
> >>
> >>As for other languages joining, look at xerces.
> >>They have separate mailing list for each language.
> >>So the simplest split would be:
> >>commons-j-dev => jakarta-commons
> >>commons-c-dev
> >>commons-p-dev
> >>
> >>For starting up new cross language initiatives a better medium can be
> >>found. A shared wiki, newsletter, ...
> >>
> >>Once a component has multiple implementations in multiple languages it
> >>is probably large enough to become a TLP itself (like log4j).
> >>
> >>
> >>-- Dirk
> >>
> >>
> >>Henri Yandell wrote:
> >>
> >>
> >>>[partially fantasy land/future ideas]
> >>>
> >>>The Jakarta Commons charter basically views Commons as a supplier of
> >>>Jakarta projects, and not Apache projects in general.
> >>>
> >>>With many of the Jakarta sub-projects moving to TLP status [ie)
> >>>ant.apache.org etc], this is increasingly untrue. Jelly's main customer
> >>>is Maven for example, quite a few XxxxUtils classes in Commons came from
> >>>Ant, and a lot of code came from a partial merger with Avalon's Excalibur.
> >>>
> >>>There are two easy solutions [to think of]. The first is to change the
> >>>charter to match reality, ie) any ASF TLP is considered a client of
> >>>Jakarta Commons. The other is for Jakarta Commons to become a TLP.
> >>>
> >>>I'd like to speak for the latter suggestion, I'd also then like to suggest
> >>>a more radical [flame-likely], though obvious next step.
> >>>
> >>>Pluses I see for becoming a TLP:
> >>>
> >>>* Currently we're viewed as a bit of an odd project in that we're an
> >>>umbrella project child of an umbrella project. Removing one of these
> >>>layers will improve the view that we have strong awareness of what's going
> >>>on and we would report directly to the board.
> >>>
> >>>* It helps get us into the ASF community. We're a bit hidden away from new
> >>>TLP Java projects, such as the currently incubating Directory project, and
> >>>a TLP placement would lead to more involvement and a larger community
> >>>spread as new Java projects arrive there.
> >>>
> >>>* There's community interest in a TLP Commons, and as a community we have
> >>>a large amount of knowledge we can bring to the table.
> >>>
> >>>The last point suggests an obvious next step, which is some kind of
> >>>merging with the Apache Commons project. I would like to suggest that the
> >>>way we do this is that, J-C goes to TLP, with all its current rules and
> >>>community, A-C projects join J-C [currently just Serf, though a
> >>>*libtool project that's something to do with compiling C is likely to join
> >>>A-C too], J-C removes its Java-centric view and allows any language to
> >>>join.
> >>>
> >>>The things I believe we should push for is that our current J-C group
> >>>should not try to de-java ourselves, but that we allow the A/J-C community
> >>>to choose its own delineations over time and not try and set them up to
> >>>begin with. Our mail lists would stay the same and they would join, and
> >>>over time we would decide, much like httpclient in the past, whether we
> >>>need new mail lists.
> >>>
> >>>The PMC for such a thing would be based on all active committers, so no
> >>>real change than the current way in which the J-C bazaar is handled.
> >>>
> >>>I think the ASF infrastructure group are going to want ASF projects to be
> >>>using subversion rather than cvs at some point in the future, and the
> >>>current A-C community has good subversion understanding with which to help
> >>>us if that should come to pass.
> >>>
> >>>There are also obvious ties when similar domain products, serf/httpclient,
> >>>are able to communicate more openly and easily.
> >>>
> >>>---
> >>>
> >>>Does anyone have any negatives/positives of such a thing? Does it make any
> >>>sense for the future? Does it harm/help J-C?
> >>>
> >>>Or am I just suggesting evil thoughts?
> >>>
> >>>Hen
> >>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>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
> >
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Commons - TLP
Posted by Dirk Verbeeck <di...@pandora.be>.
Maybe Jarkarta should take up the role of a Java@Apache gatekeeper.
Something like the java foundary at sourceforge but with the
additional task to bring all the (independent) java communities
together and provide a vision for the Java@Apache future.
-- Dirk
Henri Yandell wrote:
> The Jakarta brand may be interpreted to be: "web-based server-side code".
> It's definitely not Java@Apache anymore.
>
> It's only Java@Apache in the same way that people thought Jakarta==Tomcat
> and Jakarta was separate from ASF.
>
> Xerces is a very good example of a group who could happily be gaining from
> the a same-function mailing list, and yet their community has chosen not
> to share one mailing list [I assume]. So a good argument for us to use
> for some language separation between Commons'es.
>
> Hen
>
> On Fri, 19 Dec 2003, Dirk Verbeeck wrote:
>
>
>>I agree with the statement that the Jakarta Commons charter needs an
>>update and there is also nothing against becoming a TLP and reporting
>>directly to the board.
>>
>>But we should keep the Jakarta brand. Jakarta as the main java entry
>>point at Apache and as a provider for the java news/download is
>>important I think. (see also general@jakarta)
>>
>>I think a lot of people think "Jakarta" when you ask for java from
>>apache. The jakarta-commons is then a logical place for all reusable
>>java components. (and yes I think the java components in db-commons
>>would benefit from moving to jakarta-commons)
>>
>>As for other languages joining, look at xerces.
>>They have separate mailing list for each language.
>>So the simplest split would be:
>>commons-j-dev => jakarta-commons
>>commons-c-dev
>>commons-p-dev
>>
>>For starting up new cross language initiatives a better medium can be
>>found. A shared wiki, newsletter, ...
>>
>>Once a component has multiple implementations in multiple languages it
>>is probably large enough to become a TLP itself (like log4j).
>>
>>
>>-- Dirk
>>
>>
>>Henri Yandell wrote:
>>
>>
>>>[partially fantasy land/future ideas]
>>>
>>>The Jakarta Commons charter basically views Commons as a supplier of
>>>Jakarta projects, and not Apache projects in general.
>>>
>>>With many of the Jakarta sub-projects moving to TLP status [ie)
>>>ant.apache.org etc], this is increasingly untrue. Jelly's main customer
>>>is Maven for example, quite a few XxxxUtils classes in Commons came from
>>>Ant, and a lot of code came from a partial merger with Avalon's Excalibur.
>>>
>>>There are two easy solutions [to think of]. The first is to change the
>>>charter to match reality, ie) any ASF TLP is considered a client of
>>>Jakarta Commons. The other is for Jakarta Commons to become a TLP.
>>>
>>>I'd like to speak for the latter suggestion, I'd also then like to suggest
>>>a more radical [flame-likely], though obvious next step.
>>>
>>>Pluses I see for becoming a TLP:
>>>
>>>* Currently we're viewed as a bit of an odd project in that we're an
>>>umbrella project child of an umbrella project. Removing one of these
>>>layers will improve the view that we have strong awareness of what's going
>>>on and we would report directly to the board.
>>>
>>>* It helps get us into the ASF community. We're a bit hidden away from new
>>>TLP Java projects, such as the currently incubating Directory project, and
>>>a TLP placement would lead to more involvement and a larger community
>>>spread as new Java projects arrive there.
>>>
>>>* There's community interest in a TLP Commons, and as a community we have
>>>a large amount of knowledge we can bring to the table.
>>>
>>>The last point suggests an obvious next step, which is some kind of
>>>merging with the Apache Commons project. I would like to suggest that the
>>>way we do this is that, J-C goes to TLP, with all its current rules and
>>>community, A-C projects join J-C [currently just Serf, though a
>>>*libtool project that's something to do with compiling C is likely to join
>>>A-C too], J-C removes its Java-centric view and allows any language to
>>>join.
>>>
>>>The things I believe we should push for is that our current J-C group
>>>should not try to de-java ourselves, but that we allow the A/J-C community
>>>to choose its own delineations over time and not try and set them up to
>>>begin with. Our mail lists would stay the same and they would join, and
>>>over time we would decide, much like httpclient in the past, whether we
>>>need new mail lists.
>>>
>>>The PMC for such a thing would be based on all active committers, so no
>>>real change than the current way in which the J-C bazaar is handled.
>>>
>>>I think the ASF infrastructure group are going to want ASF projects to be
>>>using subversion rather than cvs at some point in the future, and the
>>>current A-C community has good subversion understanding with which to help
>>>us if that should come to pass.
>>>
>>>There are also obvious ties when similar domain products, serf/httpclient,
>>>are able to communicate more openly and easily.
>>>
>>>---
>>>
>>>Does anyone have any negatives/positives of such a thing? Does it make any
>>>sense for the future? Does it harm/help J-C?
>>>
>>>Or am I just suggesting evil thoughts?
>>>
>>>Hen
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: Commons - TLP
Posted by Henri Yandell <ba...@generationjava.com>.
The Jakarta brand may be interpreted to be: "web-based server-side code".
It's definitely not Java@Apache anymore.
It's only Java@Apache in the same way that people thought Jakarta==Tomcat
and Jakarta was separate from ASF.
Xerces is a very good example of a group who could happily be gaining from
the a same-function mailing list, and yet their community has chosen not
to share one mailing list [I assume]. So a good argument for us to use
for some language separation between Commons'es.
Hen
On Fri, 19 Dec 2003, Dirk Verbeeck wrote:
> I agree with the statement that the Jakarta Commons charter needs an
> update and there is also nothing against becoming a TLP and reporting
> directly to the board.
>
> But we should keep the Jakarta brand. Jakarta as the main java entry
> point at Apache and as a provider for the java news/download is
> important I think. (see also general@jakarta)
>
> I think a lot of people think "Jakarta" when you ask for java from
> apache. The jakarta-commons is then a logical place for all reusable
> java components. (and yes I think the java components in db-commons
> would benefit from moving to jakarta-commons)
>
> As for other languages joining, look at xerces.
> They have separate mailing list for each language.
> So the simplest split would be:
> commons-j-dev => jakarta-commons
> commons-c-dev
> commons-p-dev
>
> For starting up new cross language initiatives a better medium can be
> found. A shared wiki, newsletter, ...
>
> Once a component has multiple implementations in multiple languages it
> is probably large enough to become a TLP itself (like log4j).
>
>
> -- Dirk
>
>
> Henri Yandell wrote:
>
> > [partially fantasy land/future ideas]
> >
> > The Jakarta Commons charter basically views Commons as a supplier of
> > Jakarta projects, and not Apache projects in general.
> >
> > With many of the Jakarta sub-projects moving to TLP status [ie)
> > ant.apache.org etc], this is increasingly untrue. Jelly's main customer
> > is Maven for example, quite a few XxxxUtils classes in Commons came from
> > Ant, and a lot of code came from a partial merger with Avalon's Excalibur.
> >
> > There are two easy solutions [to think of]. The first is to change the
> > charter to match reality, ie) any ASF TLP is considered a client of
> > Jakarta Commons. The other is for Jakarta Commons to become a TLP.
> >
> > I'd like to speak for the latter suggestion, I'd also then like to suggest
> > a more radical [flame-likely], though obvious next step.
> >
> > Pluses I see for becoming a TLP:
> >
> > * Currently we're viewed as a bit of an odd project in that we're an
> > umbrella project child of an umbrella project. Removing one of these
> > layers will improve the view that we have strong awareness of what's going
> > on and we would report directly to the board.
> >
> > * It helps get us into the ASF community. We're a bit hidden away from new
> > TLP Java projects, such as the currently incubating Directory project, and
> > a TLP placement would lead to more involvement and a larger community
> > spread as new Java projects arrive there.
> >
> > * There's community interest in a TLP Commons, and as a community we have
> > a large amount of knowledge we can bring to the table.
> >
> > The last point suggests an obvious next step, which is some kind of
> > merging with the Apache Commons project. I would like to suggest that the
> > way we do this is that, J-C goes to TLP, with all its current rules and
> > community, A-C projects join J-C [currently just Serf, though a
> > *libtool project that's something to do with compiling C is likely to join
> > A-C too], J-C removes its Java-centric view and allows any language to
> > join.
> >
> > The things I believe we should push for is that our current J-C group
> > should not try to de-java ourselves, but that we allow the A/J-C community
> > to choose its own delineations over time and not try and set them up to
> > begin with. Our mail lists would stay the same and they would join, and
> > over time we would decide, much like httpclient in the past, whether we
> > need new mail lists.
> >
> > The PMC for such a thing would be based on all active committers, so no
> > real change than the current way in which the J-C bazaar is handled.
> >
> > I think the ASF infrastructure group are going to want ASF projects to be
> > using subversion rather than cvs at some point in the future, and the
> > current A-C community has good subversion understanding with which to help
> > us if that should come to pass.
> >
> > There are also obvious ties when similar domain products, serf/httpclient,
> > are able to communicate more openly and easily.
> >
> > ---
> >
> > Does anyone have any negatives/positives of such a thing? Does it make any
> > sense for the future? Does it harm/help J-C?
> >
> > Or am I just suggesting evil thoughts?
> >
> > Hen
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Commons - TLP
Posted by Dirk Verbeeck <di...@pandora.be>.
I agree with the statement that the Jakarta Commons charter needs an
update and there is also nothing against becoming a TLP and reporting
directly to the board.
But we should keep the Jakarta brand. Jakarta as the main java entry
point at Apache and as a provider for the java news/download is
important I think. (see also general@jakarta)
I think a lot of people think "Jakarta" when you ask for java from
apache. The jakarta-commons is then a logical place for all reusable
java components. (and yes I think the java components in db-commons
would benefit from moving to jakarta-commons)
As for other languages joining, look at xerces.
They have separate mailing list for each language.
So the simplest split would be:
commons-j-dev => jakarta-commons
commons-c-dev
commons-p-dev
For starting up new cross language initiatives a better medium can be
found. A shared wiki, newsletter, ...
Once a component has multiple implementations in multiple languages it
is probably large enough to become a TLP itself (like log4j).
-- Dirk
Henri Yandell wrote:
> [partially fantasy land/future ideas]
>
> The Jakarta Commons charter basically views Commons as a supplier of
> Jakarta projects, and not Apache projects in general.
>
> With many of the Jakarta sub-projects moving to TLP status [ie)
> ant.apache.org etc], this is increasingly untrue. Jelly's main customer
> is Maven for example, quite a few XxxxUtils classes in Commons came from
> Ant, and a lot of code came from a partial merger with Avalon's Excalibur.
>
> There are two easy solutions [to think of]. The first is to change the
> charter to match reality, ie) any ASF TLP is considered a client of
> Jakarta Commons. The other is for Jakarta Commons to become a TLP.
>
> I'd like to speak for the latter suggestion, I'd also then like to suggest
> a more radical [flame-likely], though obvious next step.
>
> Pluses I see for becoming a TLP:
>
> * Currently we're viewed as a bit of an odd project in that we're an
> umbrella project child of an umbrella project. Removing one of these
> layers will improve the view that we have strong awareness of what's going
> on and we would report directly to the board.
>
> * It helps get us into the ASF community. We're a bit hidden away from new
> TLP Java projects, such as the currently incubating Directory project, and
> a TLP placement would lead to more involvement and a larger community
> spread as new Java projects arrive there.
>
> * There's community interest in a TLP Commons, and as a community we have
> a large amount of knowledge we can bring to the table.
>
> The last point suggests an obvious next step, which is some kind of
> merging with the Apache Commons project. I would like to suggest that the
> way we do this is that, J-C goes to TLP, with all its current rules and
> community, A-C projects join J-C [currently just Serf, though a
> *libtool project that's something to do with compiling C is likely to join
> A-C too], J-C removes its Java-centric view and allows any language to
> join.
>
> The things I believe we should push for is that our current J-C group
> should not try to de-java ourselves, but that we allow the A/J-C community
> to choose its own delineations over time and not try and set them up to
> begin with. Our mail lists would stay the same and they would join, and
> over time we would decide, much like httpclient in the past, whether we
> need new mail lists.
>
> The PMC for such a thing would be based on all active committers, so no
> real change than the current way in which the J-C bazaar is handled.
>
> I think the ASF infrastructure group are going to want ASF projects to be
> using subversion rather than cvs at some point in the future, and the
> current A-C community has good subversion understanding with which to help
> us if that should come to pass.
>
> There are also obvious ties when similar domain products, serf/httpclient,
> are able to communicate more openly and easily.
>
> ---
>
> Does anyone have any negatives/positives of such a thing? Does it make any
> sense for the future? Does it harm/help J-C?
>
> Or am I just suggesting evil thoughts?
>
> Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org