You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2003/11/10 19:18:30 UTC
Benefits of Apache Commons was Re: [REQUEST] Product groupings
--On Monday, November 10, 2003 6:04 AM -0500 "Geir Magnusson Jr."
<ge...@optonline.net> wrote:
> Is there a good post describing the benefit of these changes? I don't
> understand the upside of moving oro and regex from one umbrella to another
> umbrella, nor trying to get j-c projects to move to a-c. I see j-c as a
> vibrant and prolific community, and wonder about the effects of breaking it
> apart.
>
> I either missed the point somewhere (likely) or don't get it (also likely).
Okay, we've gone over these before, but I'll try to restate what I believe the
benefits to be for the newcomers. Others are welcome to chime in and comment.
- I don't quite believe it'll be the same sort of umbrella as J-C or Jakarta
itself. We're trying to advocate that groupings should receive their own
topic-centric mailing list. We're trying to advocate a higher degree of
interaction with the PMC, etc. From all reports, J-C is starting to collapse
under its own weight. Something has to give.
- It's isn't quite a lateral move as you'd make it out to be. I believe it,
at best, would be cutting out one level of bureaucracy (namely the Jakarta
PMC) and restoring power to committers working on code. This has the
advantage of allowing the actual developers working on the projects to have a
voice in the PMC (and, legally, this is as they are required). I've heard
concerns from J-C folks that they don't really have any direction from the
Jakarta PMC on what to do, nor do they have any say. Yet, in A-C, there would
be *at least* one Commons PMC member per project who is active - the Commons
PMC needs to ensure that as part of its oversight responsibility.
- A chance to re-organize projects that aren't 'quite big enough' for TLP
status that are meant for reusability under one shared PMC. I believe that a
lot of 'small' projects will share common needs and requirements: a PMC that
understands that can be extremely beneficial with the right processes and
tools in place.
- It's harder to build communities around reusable libraries that don't have
any direct user interfaces: it takes a lot of time and effort and doesn't
usually start with the community size that mandates TLP status. And, I'll
point out that this isn't quite the same as the incubator - which is only
meant as a legal checklist.
- A learning place where these reusability projects (or groupings of projects)
that do become 'big enough' to become TLPs. As these collections of
functional groupings are defined and projects start to develop communities
that can manage themselves, I believe the Commons PMC should advocate that
they should be promoted en masse as a new TLP. This respects the current
feelings (among some) that the ASF should reorganize around very specific TLPs
rather than broad PMCs.
- Yet, we will have to find the balance on what should be spun off and what
shouldn't be. IMHO, the ideal code in Commons is one that is 'done' and
doesn't need much work or oversight. Hence, creating a TLP doesn't make sense
for certain classes of libraries as when they're done, they're 'done.' You've
created the 'perfect' math library. Yay.
- From my C-centric perspective, a place where I can develop reusable code and
libraries as there are no PMCs willing to accept reusable C libraries anywhere
in the ASF such as serf. (APR did for a little while, but that was under
extreme protest.) So, I'm merely here to scratch my own itch as I'd expect
most people should be, too.
Hope this begins to answer your question. -- justin
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Tim O'Brien <to...@discursive.com>.
On Mon, 2003-11-10 at 13:30, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 14:09:20 -0500 Tim O'Brien
> <to...@discursive.com> wrote:
>
> > ....(I see J-C turning
> > into an umbrella project inside of an umbrella project [Jakarta]).
>
> The problem with that is there may be no oversight from the Board/Jakarta
> PMC if you add yet another layer. That's a serious problem. I think the
> only layer of bureaucracy should be the PMC. Anything else, IMHO, should
> be only about code.
Justin, some clarification, I think it is a bad thing that J-C has turned
into an umbrella project within an umbrella project. I wasn't
proposing that as a viable structure.
Tim
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 05:52 PM, robert burrell donkin wrote:
> On 10 Nov 2003, at 19:30, Justin Erenkrantz wrote:
>
>> --On Monday, November 10, 2003 14:09:20 -0500 Tim O'Brien
>> <to...@discursive.com> wrote:
>>
>>> I think that J-C has some (easily remedied) problems - (I see J-C
>>> turning
>>> into an umbrella project inside of an umbrella project [Jakarta]).
>>
>> The problem with that is there may be no oversight from the
>> Board/Jakarta PMC if you add yet another layer. That's a serious
>> problem. I think the only layer of bureaucracy should be the PMC.
>> Anything else, IMHO, should be only about code.
>
> IMHO the real mistake that jakarta made was to allow umbrella
> sub-projects. once a sub-projects becomes either too big or too
> diverse for one mailing list and one cvs repository, it should either
> take steps to reduce it's size (by spinning offer components, for
> example) or by applying for top level project status.
>
> jakarta-commons has been a tremendous success but now the limits of a
> single list and repository are starting to be brought into focus. we
> need to take steps now to ensure that the success of jakarta-commons
> can continue but without the formation of any more sub-sub-projects.
I don't know of the repository problem, but I have a suggestion to
solve the mail list problem...
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, robert burrell donkin wrote:
> jakarta-commons has been a tremendous success but now the limits of a
> single list and repository are starting to be brought into focus. we
> need to take steps now to ensure that the success of jakarta-commons
> can continue but without the formation of any more sub-sub-projects.
Ahhh....
Jakarta/Jakarta-Commons/Jelly/Taglibs ;)
Smell the fear.
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by robert burrell donkin <rd...@apache.org>.
On 10 Nov 2003, at 19:30, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 14:09:20 -0500 Tim O'Brien
> <to...@discursive.com> wrote:
>
>> I think that J-C has some (easily remedied) problems - (I see J-C
>> turning
>> into an umbrella project inside of an umbrella project [Jakarta]).
>
> The problem with that is there may be no oversight from the
> Board/Jakarta PMC if you add yet another layer. That's a serious
> problem. I think the only layer of bureaucracy should be the PMC.
> Anything else, IMHO, should be only about code.
IMHO the real mistake that jakarta made was to allow umbrella
sub-projects. once a sub-projects becomes either too big or too diverse
for one mailing list and one cvs repository, it should either take
steps to reduce it's size (by spinning offer components, for example)
or by applying for top level project status.
jakarta-commons has been a tremendous success but now the limits of a
single list and repository are starting to be brought into focus. we
need to take steps now to ensure that the success of jakarta-commons
can continue but without the formation of any more sub-sub-projects.
- robert
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, November 10, 2003 14:09:20 -0500 Tim O'Brien
<to...@discursive.com> wrote:
> I think that J-C has some (easily remedied) problems - (I see J-C turning
> into an umbrella project inside of an umbrella project [Jakarta]).
The problem with that is there may be no oversight from the Board/Jakarta
PMC if you add yet another layer. That's a serious problem. I think the
only layer of bureaucracy should be the PMC. Anything else, IMHO, should
be only about code.
> This seems to be in direct opposition to many things I've heard in the
> last few months. It is my understanding that either the Board or the
> Members decided that every active commiter should be on the PMC.
Anyone making a release and is substantially contributing to the project
should be on the PMC. But, does the person who only commits an occassional
patch and doesn't interest themselves in the project be on the PMC? That's
debatable. But, if you are actively contributing to the project, yes, you
should be on the PMC. Sorry if that wasn't clear. -- justin
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Tim O'Brien <to...@discursive.com>.
On Mon, 10 Nov 2003, Justin Erenkrantz wrote:
> - I don't quite believe it'll be the same sort of umbrella as J-C or Jakarta
> itself. We're trying to advocate that groupings should receive their own
> topic-centric mailing list. We're trying to advocate a higher degree of
> interaction with the PMC, etc. From all reports, J-C is starting to collapse
> under its own weight. Something has to give.
I think it has problems, but "collapsing under..." is a little too
dramatic.
I think that J-C has some (easily remedied) problems - (I see J-C turning
into an umbrella project inside of an umbrella project [Jakarta]).
People decide that we need another "services framework" or a "math
library", and from my perspective J-C offers the path of least resistance.
Math as first proposed was to be a simple "package" ocntaining a limited
set of utilities - it has since grown to something much larger than
originally intended. Things like HiveMind, Jelly, Math - are not simply
common components, I don't see why they wouldn't be either TLP or
another subprojects.
I also think that J-C works very well in projects like Commons Lang,
BeanUtils, Digester, Codec, EL, JXPath, etc. - I see no reason to move
something like Digester to A-C. These projects do not have the volume of
dev mail to sustain an independent community, and are very limited in
scope.
> - It's isn't quite a lateral move as you'd make it out to be. I believe it,
> at best, would be cutting out one level of bureaucracy (namely the Jakarta
> PMC) and restoring power to committers working on code. This has the
> advantage of allowing the actual developers working on the projects to have a
> voice in the PMC (and, legally, this is as they are required). I've heard
> concerns from J-C folks that they don't really have any direction from the
> Jakarta PMC on what to do, nor do they have any say. Yet, in A-C, there would
> be *at least* one Commons PMC member per project who is active - the Commons
> PMC needs to ensure that as part of its oversight responsibility.
This seems to be in direct opposition to many things I've heard in the
last few months. It is my understanding that either the Board or the
Members decided that every active commiter should be on the PMC.
> - A learning place where these reusability projects (or groupings of projects)
> that do become 'big enough' to become TLPs. As these collections of
> functional groupings are defined and projects start to develop communities
> that can manage themselves, I believe the Commons PMC should advocate that
> they should be promoted en masse as a new TLP. This respects the current
> feelings (among some) that the ASF should reorganize around very specific TLPs
> rather than broad PMCs.
+1 there should be no aversion to have many TLPs - I point to successful
communities outside of the ASF as proof of what focus can bring (Hibernate
and FreeMarker are just two examples).
Tim O'Brien
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 10, 2003 at 08:55:25PM -0500, Henri Yandell wrote:
> Gonna repeat a point, but would like it recorded here too. If we come over
> to Apache Commons PMC, we have to share control with people who are not
> part of the community [from our current mindset].
I think that's a valid fear and this project should organize itself
in such a way that those kinds of power/control issues are avoided
(or at least left up to those who are doing the work).
> There could also be a fear that we'll be lead by a small elite of non-J-C
> members in how a PMC works.
If there are things wrong with any PMC, then they need to be fixed.
Unfortunately, there are multiple ways to get anything done [at the ASF].
Anyway, I don't think this is a legit fear of moving to A-C as long
as the power over the code is kept in the hands of the people who care
and the people who are doing the work*.
* And I believe we can do that while maintaining legal ASF oversight.
-aaron
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
Thanks for doing the legwork :)
Hen
On Mon, 10 Nov 2003, Rodney Waldhoff wrote:
> For the record, all 24 of the current jakarta-commons components list one
> or more Jakarta PMC members as committers in their status or team-list
> files. Most of them list more than one PMC member.
>
> On Mon, 10 Nov 2003, Justin Erenkrantz wrote:
>
> > --On Monday, November 10, 2003 21:05:16 +0000 Stephen Colebourne
> > <sc...@btopenworld.com> wrote:
> >
> > > What I see and what I fear is having the control of the projects which I
> > > currently have being taken away and placed in the hands of people who have
> > > committed no code, have answered no user queries, don't use the language
> > > (Java) and have no sense of the complex component history and personality
> > > matrix of the commons community.
> >
> > I think you're missing the fact that you'd (or any other sizable committers
> > on the projects that would migrate over) be on the Apache Commons PMC if
> > you were to bring a project here. So, you would be legally empowered to
> > control the project.
> >
> > The whole point is to *legally* and *ethically* return control to the
> > committers by having them on the PMC - not to have the power vested in some
> > remote bureaucratic entity like it is in Jakarta. -- justin
> >
>
> - Rod <http://radio.weblogs.com/0122027/>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Rodney Waldhoff <rw...@apache.org>.
For the record, all 24 of the current jakarta-commons components list one
or more Jakarta PMC members as committers in their status or team-list
files. Most of them list more than one PMC member.
On Mon, 10 Nov 2003, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 21:05:16 +0000 Stephen Colebourne
> <sc...@btopenworld.com> wrote:
>
> > What I see and what I fear is having the control of the projects which I
> > currently have being taken away and placed in the hands of people who have
> > committed no code, have answered no user queries, don't use the language
> > (Java) and have no sense of the complex component history and personality
> > matrix of the commons community.
>
> I think you're missing the fact that you'd (or any other sizable committers
> on the projects that would migrate over) be on the Apache Commons PMC if
> you were to bring a project here. So, you would be legally empowered to
> control the project.
>
> The whole point is to *legally* and *ethically* return control to the
> committers by having them on the PMC - not to have the power vested in some
> remote bureaucratic entity like it is in Jakarta. -- justin
>
- Rod <http://radio.weblogs.com/0122027/>
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 04:26 PM, Rodney Waldhoff wrote:
> On Mon, 10 Nov 2003, Geir Magnusson Jr. wrote:
>
>>
>> On Monday, November 10, 2003, at 04:20 PM, Justin Erenkrantz wrote:
>>
>>> --On Monday, November 10, 2003 21:05:16 +0000 Stephen Colebourne
>>> <sc...@btopenworld.com> wrote:
>>>
>>>> What I see and what I fear is having the control of the projects
>>>> which I
>>>> currently have being taken away and placed in the hands of people
>>>> who
>>>> have
>>>> committed no code, have answered no user queries, don't use the
>>>> language
>>>> (Java) and have no sense of the complex component history and
>>>> personality
>>>> matrix of the commons community.
>>>
>>> I think you're missing the fact that you'd (or any other sizable
>>> committers on the projects that would migrate over) be on the Apache
>>> Commons PMC if you were to bring a project here. So, you would be
>>> legally empowered to control the project.
>>>
>>> The whole point is to *legally* and *ethically* return control to the
>>> committers by having them on the PMC - not to have the power vested
>>> in
>>> some remote bureaucratic entity like it is in Jakarta. -- justin
>>>
>>
>> Why do you call it a 'remote, bureaucratic entity'? I would argue
>> that
>> it logically can't be if the allegation that it does nothing is true
>> :)
>>
>> I assume the problem just goes away if each commons component has
>> representation on the PMC?
>
> Or similarly, if jakarta-commons were to become a top level project?
>
I guess that would work too. What I was trying to preserve though is
the original 'community core' that j-c provided in jakarta. Maybe we
don't need it anymore.
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Rodney Waldhoff <rw...@apache.org>.
On Mon, 10 Nov 2003, Geir Magnusson Jr. wrote:
>
> On Monday, November 10, 2003, at 04:20 PM, Justin Erenkrantz wrote:
>
> > --On Monday, November 10, 2003 21:05:16 +0000 Stephen Colebourne
> > <sc...@btopenworld.com> wrote:
> >
> >> What I see and what I fear is having the control of the projects
> >> which I
> >> currently have being taken away and placed in the hands of people who
> >> have
> >> committed no code, have answered no user queries, don't use the
> >> language
> >> (Java) and have no sense of the complex component history and
> >> personality
> >> matrix of the commons community.
> >
> > I think you're missing the fact that you'd (or any other sizable
> > committers on the projects that would migrate over) be on the Apache
> > Commons PMC if you were to bring a project here. So, you would be
> > legally empowered to control the project.
> >
> > The whole point is to *legally* and *ethically* return control to the
> > committers by having them on the PMC - not to have the power vested in
> > some remote bureaucratic entity like it is in Jakarta. -- justin
> >
>
> Why do you call it a 'remote, bureaucratic entity'? I would argue that
> it logically can't be if the allegation that it does nothing is true :)
>
> I assume the problem just goes away if each commons component has
> representation on the PMC?
Or similarly, if jakarta-commons were to become a top level project?
- Rod <http://radio.weblogs.com/0122027/>
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 04:20 PM, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 21:05:16 +0000 Stephen Colebourne
> <sc...@btopenworld.com> wrote:
>
>> What I see and what I fear is having the control of the projects
>> which I
>> currently have being taken away and placed in the hands of people who
>> have
>> committed no code, have answered no user queries, don't use the
>> language
>> (Java) and have no sense of the complex component history and
>> personality
>> matrix of the commons community.
>
> I think you're missing the fact that you'd (or any other sizable
> committers on the projects that would migrate over) be on the Apache
> Commons PMC if you were to bring a project here. So, you would be
> legally empowered to control the project.
>
> The whole point is to *legally* and *ethically* return control to the
> committers by having them on the PMC - not to have the power vested in
> some remote bureaucratic entity like it is in Jakarta. -- justin
>
Why do you call it a 'remote, bureaucratic entity'? I would argue that
it logically can't be if the allegation that it does nothing is true :)
I assume the problem just goes away if each commons component has
representation on the PMC?
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 21:05:16 +0000 Stephen Colebourne
> <sc...@btopenworld.com> wrote:
>
> > What I see and what I fear is having the control of the projects which I
> > currently have being taken away and placed in the hands of people who have
> > committed no code, have answered no user queries, don't use the language
> > (Java) and have no sense of the complex component history and personality
> > matrix of the commons community.
>
> I think you're missing the fact that you'd (or any other sizable committers
> on the projects that would migrate over) be on the Apache Commons PMC if
> you were to bring a project here. So, you would be legally empowered to
> control the project.
Gonna repeat a point, but would like it recorded here too. If we come over
to Apache Commons PMC, we have to share control with people who are not
part of the community [from our current mindset].
There could also be a fear that we'll be lead by a small elite of non-J-C
members in how a PMC works.
> The whole point is to *legally* and *ethically* return control to the
> committers by having them on the PMC - not to have the power vested in some
> remote bureaucratic entity like it is in Jakarta. -- justin
Which is being solved. If the issue is legal, then the board should be
telling J-C it must move to A-C, not offering a legal/ethical solution for
them to move to. Does 'legal' allow for greyness? ie) Jakarta is
less-legal, but still legal?
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, November 10, 2003 21:05:16 +0000 Stephen Colebourne
<sc...@btopenworld.com> wrote:
> What I see and what I fear is having the control of the projects which I
> currently have being taken away and placed in the hands of people who have
> committed no code, have answered no user queries, don't use the language
> (Java) and have no sense of the complex component history and personality
> matrix of the commons community.
I think you're missing the fact that you'd (or any other sizable committers
on the projects that would migrate over) be on the Apache Commons PMC if
you were to bring a project here. So, you would be legally empowered to
control the project.
The whole point is to *legally* and *ethically* return control to the
committers by having them on the PMC - not to have the power vested in some
remote bureaucratic entity like it is in Jakarta. -- justin
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Justin Erenkrantz" <ju...@erenkrantz.com>
To: <ge...@commons.apache.org>
> > fostered to scratch the itch of another community, Jakarta. And within
> > commons, mini-communities were formed around each component. There's an
> > interesting fractal-like structure to it, and one that joins unrelated
> > Jakarta subprojects in interesting ways. I think commons glued lots of
> > jakarta sub-projects together. While I think that a-c could be a good
> > idea, I fear the difference may be that the communities you are trying
to
> > bring together don't have enough in common. People have been learning
> > this the hard way (for example, Yugoslavia...).
>
> I think you're misunderstanding our goals here. We're not trying to force
> anyone to come together. We're offering an alternative organizational
> structure to J-C that may be more conducive to certain communities. If a
> component is happy in J-C land, it can stay there. But, if they want to
> truly be able to manage the project themselves (as I believe each project
> should), then I think A-C is a compelling alternative. -- justin
What I see and what I fear is having the control of the projects which I
currently have being taken away and placed in the hands of people who have
committed no code, have answered no user queries, don't use the language
(Java) and have no sense of the complex component history and personality
matrix of the commons community.
Stephen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Aaron Bannert <aa...@clove.org>.
On Mon, Nov 10, 2003 at 01:14:30PM -0800, Justin Erenkrantz wrote:
> ...when the only
> active contributors to serf are right now Greg and myself...
Hey! Just because I haven't been using your fancy-schmancy Subversion
tool doesn't mean I'm not a contributor. Most of this stuff precipitated
from our over-beer talks at AC last year. :)
-aaron
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, November 10, 2003 20:51:53 -0500 Henri Yandell
<ba...@generationjava.com> wrote:
> This is not meant to be an insulting, language-argument question, but is
> this a fundamental difference between httpd and Jakarta? When you said
What I believe is that the HTTP Server PMC has taken a strict
interpretation of their charter/mission statement. Until recently, Jakarta
has had a very liberal interpretation of their charter. I think the
current size issues has forced the Jakarta PMC to slow their acceptance of
new projects.
I think HTTP Server PMC is very scared about becoming too big. In fact,
we're having a discussion on dev@httpd about how to 'oversee' the httpd
development (as some think its stagnating). It was initially raised on the
PMC list, but the PMC kicked it to dev@httpd as it's more of a
subproject-level (i.e. httpd-2.x codebase) than a strict PMC issue.
> Having also heard that APR was largely the work of one developer (?), do
> we have a fundamental different in that Jakarta is more of a bazaar, which
> explains the lack of centralisation that might be found in httpd?
One person was the energizer bunny (Ryan) during the initial APR fork (as
it derived largely from code written in httpd), but to say that he was the
only person isn't probably accurate. A lot of people are responsible for
the current code and maintain it. Ryan has since ceased all ASF
involvement, and the project still continues.
APR is probably right now scared of going to 1.0 and most of the projects
that use it are relatively happy. But, 1.0 will happen soon. ;-)
> into httpd modules etc, so have never seen how the other half live. Are
> you guys less anarchic, more controlled, and designed for a lot less
> active developers per codebase?
The 'official' subprojects of HTTP Server are apreq, mod_python, and
httpd-test (which includes perl-framework and flood). (Docs isn't really a
subproject per se.) All of the critical contributors from those
subprojects are on the PMC. New committers must be approved by the entire
HTTP Server PMC, but generally, if the mod_python PMCers want a committer,
that person is approved. And, everyone who can make releases is on the PMC.
I don't have numbers of committers for projects, but you could take a look
at /home/cvs/CVSROOT/avail to get a counting of people who are on the PMC
and who just have commit access. I think RoUS's bot can tell you how many
people are subscribed to dev@apr and dev@httpd. -- justin
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, Justin Erenkrantz wrote:
> Case in point, I don't believe Serf should be a TLP. Now, if we had a
> collection of 10-15 developers all working (actively) on HTTP Client
> codebases, then perhaps a HTTP Client TLP makes sense. But, when the only
> active contributors to serf are right now Greg and myself, I think that'd
> be incredibly premature to ask for a TLP with an associated PMC.
This is not meant to be an insulting, language-argument question, but is
this a fundamental difference between httpd and Jakarta? When you said
higher in this mail that 1 or 2 developer projects should not be TLP's, I
was going to say that no Commons project out of the sandbox are likely to
be so small [though I imagine there are exceptions].
Having also heard that APR was largely the work of one developer (?), do
we have a fundamental different in that Jakarta is more of a bazaar, which
explains the lack of centralisation that might be found in httpd?
I'm just wondering. Despite great desire, I've never found time to get
into httpd modules etc, so have never seen how the other half live. Are
you guys less anarchic, more controlled, and designed for a lot less
active developers per codebase?
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, November 10, 2003 15:39:33 -0500 Sam Ruby <ru...@apache.org>
wrote:
> However, if the case is to be made that umbrella projects are not good
> things (something that I completely understand and agree with), then I
> would suggest that the current discussions on having product groupings
> within commons (see subject of this message thread) should cease
> immediately.
>
> The goal should be that one group = one project = one PMC.
I think the groupings proposed here would be initially too small to warrant
their own PMC as I believe one or two person efforts should not be a TLP,
but rather something along the lines of 10-15 active contributors to seed a
PMC is probably about the 'right' size for a TLP to be successful.
IMHO, only after a grouping attains a certain size whereby it can manage
itself (and do so properly!) should the board support the creation of a
TLP. I believe the creation of lots of small projects would just increase
the burden of the board and would leave a lot of the projects unsure about
how to run a TLP (especially if they are from Jakarta).
Case in point, I don't believe Serf should be a TLP. Now, if we had a
collection of 10-15 developers all working (actively) on HTTP Client
codebases, then perhaps a HTTP Client TLP makes sense. But, when the only
active contributors to serf are right now Greg and myself, I think that'd
be incredibly premature to ask for a TLP with an associated PMC. -- justin
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 03:39 PM, Sam Ruby wrote:
> Greg Stein wrote:
>> On Mon, Nov 10, 2003 at 11:43:51AM -0800, Justin Erenkrantz wrote:
>>> ...
>>> The power to dictate for themselves what the project should be doing
>>> and its direction. I believe the Jakarta PMC does not do a
>>> sufficient job of oversight (if any at all). Most of the PMC
>>> responsibilities has been devolved to the committers, but without
>>> the correct organizational structure in place as mandated by the ASF
>>> bylaws. Does the board (and, indirectly, membership) have any
>>> reports on what J-C is doing?
>> In a word: no
>
> Sigh. I've pointed this out before, but perhaps this time you might
> want to write it down: http://jakarta.apache.org/site/news.html
>
> I also gave a verbal and written status of the overall project the
> last time it was requested.
>
> However, if the case is to be made that umbrella projects are not good
> things (something that I completely understand and agree with), then I
> would suggest that the current discussions on having product groupings
> within commons (see subject of this message thread) should cease
> immediately.
>
> The goal should be that one group = one project = one PMC.
>
I certainly grok the "umbrella bad" argument, although I don't agree
with it.
However, if the ASF decides that "umbrella bad", then we've got lots of
work to do. We'll have to break up XML, WebServices, Httpd and
Jakarta. I think we'll have a mess, and snuff out the collaborative
energy that those umbrella projects somehow sustain.
If we have problems, lets just fix those problems.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, Sam Ruby wrote:
> However, if the case is to be made that umbrella projects are not good
> things (something that I completely understand and agree with), then I
> would suggest that the current discussions on having product groupings
> within commons (see subject of this message thread) should cease
> immediately.
>
> The goal should be that one group = one project = one PMC.
This seems akin to Brian Behlendorf's views on a kinda-sourceforge-like
place with matrix of categories.
My chief worry here is, a lot of website work to design, create and manage
all this information.
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Sam Ruby <ru...@apache.org>.
Greg Stein wrote:
> On Mon, Nov 10, 2003 at 11:43:51AM -0800, Justin Erenkrantz wrote:
>
>>...
>>The power to dictate for themselves what the project should be doing and
>>its direction. I believe the Jakarta PMC does not do a sufficient job of
>>oversight (if any at all). Most of the PMC responsibilities has been
>>devolved to the committers, but without the correct organizational
>>structure in place as mandated by the ASF bylaws. Does the board (and,
>>indirectly, membership) have any reports on what J-C is doing?
>
> In a word: no
Sigh. I've pointed this out before, but perhaps this time you might
want to write it down: http://jakarta.apache.org/site/news.html
I also gave a verbal and written status of the overall project the last
time it was requested.
However, if the case is to be made that umbrella projects are not good
things (something that I completely understand and agree with), then I
would suggest that the current discussions on having product groupings
within commons (see subject of this message thread) should cease
immediately.
The goal should be that one group = one project = one PMC.
- Sam Ruby
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 03:19 PM, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 11:43:51AM -0800, Justin Erenkrantz wrote:
>> ...
>> The power to dictate for themselves what the project should be doing
>> and
>> its direction. I believe the Jakarta PMC does not do a sufficient
>> job of
>> oversight (if any at all). Most of the PMC responsibilities has been
>> devolved to the committers, but without the correct organizational
>> structure in place as mandated by the ASF bylaws. Does the board
>> (and,
>> indirectly, membership) have any reports on what J-C is doing?
>
> In a word: no
I want to argue about this, but I also want to be clear about one thing
- does the board require reports from every subpart of a project? I'm
distinguishing between the notion that the PCM is *responsible* for all
subparts versus required to *report* on all subparts. I won't argue
that we could do a better job as a PMC in Jakarta, and I'm doing what I
can now that I have more time to contribute to help there.
But if I went and looked at the archives of board reports, would I see
discussions of 'docs' and 'flood' every month?
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 11:43:51AM -0800, Justin Erenkrantz wrote:
> >...
> > The power to dictate for themselves what the project should be doing and
> > its direction. I believe the Jakarta PMC does not do a sufficient job of
> > oversight (if any at all). Most of the PMC responsibilities has been
> > devolved to the committers, but without the correct organizational
> > structure in place as mandated by the ASF bylaws. Does the board (and,
> > indirectly, membership) have any reports on what J-C is doing?
>
> In a word: no
Could someone please show the J-PMC the 'correct organizational
structure'? One of the hardest problems on the J-PMC is explaining just
what the point of the J-PMC is and what people are signing into when they
agree to be on it.
'Oversight' is about as well defined as the 'ASF Way'.
Greg does do a good job of pointing things out as they happen on the list,
but there is much for us to learn about our role.
Given this, if J-C were to move into A-C today as a whole, it seems we
would still be sitting there learning and being frustrated at the parts
that don't translate well to us. Maybe the J-PMC just need to invite some
more of the ASF PMC experienced members onto the J-PMC as guests to show
us the way.
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 10, 2003 at 11:43:51AM -0800, Justin Erenkrantz wrote:
>...
> The power to dictate for themselves what the project should be doing and
> its direction. I believe the Jakarta PMC does not do a sufficient job of
> oversight (if any at all). Most of the PMC responsibilities has been
> devolved to the committers, but without the correct organizational
> structure in place as mandated by the ASF bylaws. Does the board (and,
> indirectly, membership) have any reports on what J-C is doing?
In a word: no
--
Greg Stein, http://www.lyra.org/
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 14:14:30 -0500 "Geir Magnusson Jr."
> <ge...@optonline.net> wrote:
>
> > I think that this slightly misrepresents the problem, as it's not clear
> > what 'power' needs to be restored. I agree that there could and should
> > be more representation on the PMC for legal reasons, but that can be
> > achieved with a bigger PMC.
>
> The power to dictate for themselves what the project should be doing and
> its direction. I believe the Jakarta PMC does not do a sufficient job of
> oversight (if any at all). Most of the PMC responsibilities has been
The Jakarta PMC has complete oversight of the Jakarta project in that
there is no Jakarta project without a PMC member. It's possible that there
are Commons components without a PMC member and I intend to nominate to
improve this as time permits.
> devolved to the committers, but without the correct organizational
> structure in place as mandated by the ASF bylaws. Does the board (and,
> indirectly, membership) have any reports on what J-C is doing?
Membership, no idea. I've never heard it be said that it was important for
members to have a clue about Jakarta.
As for reports, I've also never heard that the board is supposed to be
reported to. In fact, we've recently hit this problem on the J-PMC. Should
things be reported to the entire PMC for 'oversight' to happen, or is it
enough that a person on the PMC is aware of the issue for 'oversight' to
be happening.
> FWIW, I tend not to use the word components because it means something
> totally different to me in my ivory tower of academia. ;-)
Commons is components :) I don't know any other word to use as
'sub-project' is wrong.
> I'm not debating the success of the J-C, but what I'm debating is that the
> Jakarta PMC has not been good about oversight or promoting projects to TLP
It is learning and growing. A lot of the change in culture for Jakarta is
about learning what the new abilities are and I don't think anyone at
Jakarta fully grasps just what they can do. For example, I suspect the
reason Hivemind has not pushed for Jakarta TLP [subTLP?] ness is that the
commiters don't realise that the vote would easily succeed. Ditto for
Math. Actually both might not succeed for the simple reason that neither
have a lot of active coding from PMC members, therefore keeping them in
Commons keeps them under oversight.
> status. And has been discussed, neither is Jakarta Commons sufficient for
> all languages. They would reject anything not written in Java (or they
> should be rejecting it as it directly violates their charter).
Yep. Despite my willingness to be convinced, and attempt to not be anti
'A-C', I think the language lines are drawn too deeply in the sand.
> > I'm not sure what you mean here. What do you define to be 'direct user
> > interface'? In commons, there is a huge community, which was created and
>
> Something a user interacts directly with. I think it's the easiest test
> for whether something belongs in 'Commons' or not. If you are writing an
> application the user executes directly, I don't think that belongs in
> Commons.
An argument that's not really happened. Generic reusable servlets. These
should still be in Commons according to the spec, even if real-users would
interact with them. There are other examples [Jelly tagilbs, Hivemind
services, etc].
Personally I think it is that Commons should have nothing that requires
Religion. I could quite happily have a reusable AWT/Swing component in
Commons, but if I discover that there is some framework I must write
components to fit into, then it isn't Commons, but a religion I must
proscribe to.
> > fostered to scratch the itch of another community, Jakarta. And within
> > commons, mini-communities were formed around each component. There's an
> > interesting fractal-like structure to it, and one that joins unrelated
> > Jakarta subprojects in interesting ways. I think commons glued lots of
> > jakarta sub-projects together. While I think that a-c could be a good
> > idea, I fear the difference may be that the communities you are trying to
> > bring together don't have enough in common. People have been learning
> > this the hard way (for example, Yugoslavia...).
>
> I think you're misunderstanding our goals here. We're not trying to force
> anyone to come together. We're offering an alternative organizational
> structure to J-C that may be more conducive to certain communities. If a
> component is happy in J-C land, it can stay there. But, if they want to
> truly be able to manage the project themselves (as I believe each project
> should), then I think A-C is a compelling alternative. -- justin
As a 'user' of A-C/J-C, it's going to be hard to become schizo enough to
use it. I'll have to use CVS in one and SVN in another. Fit one set of
rules in one and another in the other. If I worked on one component, then
sure, I might leap over and give up the old, but at the moment I'll end up
with two utterly different work-styles depending on which url the code
happens to live at.
On the not trying to force together, it doesn't match Greg's aversion to
J-C as a TLP [which I'm not fully in favour of but ought to be 'legal'].
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Tim O'Brien <to...@discursive.com>.
On Mon, 2003-11-10 at 16:15, robert burrell donkin wrote:
> for a few months now, i've been subscribed to most of the jakarta
> sub-project mailing lists. it started out with the mirroring but i
> stayed as an experiment (partly as a result of the constant criticism
> that the jakarta-pmc receives). last week my email client died. i've
> spent all last week rebuilding a new IMAP server and transferring my
> (very precious) email onto it. i still think that it's possible to
> supervise something as big as jakarta - but only just. i don't spend
> very much time coding now :(
>
Robert, this is the central problem here. You write good code, and
I want to see more of it. We need people on the PMC to be coding,
not supervising.
Re: J-C oversight (was: Benefits of Apache Commons)
Posted by robert burrell donkin <rd...@apache.org>.
On 13 Nov 2003, at 01:05, Stephen Colebourne wrote:
> From: "robert burrell donkin" <rd...@apache.org>
>> jakarta-commons is high traffic but the worries about scalability are
>> not to do with supervision but whether normal developers can continue
>> to be attracted.
>
> I've been quiet for a while, but I wanted to agree with this last
> statement.
> Its not about supervision in j-c, but keeping attracting new ideas and
> committers.
>
> I would suggest
> a) the j-c mailing list is very high traffic
> b) some newcomers/contributers are definitely being put off by this
> c) the ability for j-c to accept new components must eventually be
> limited
> by the one mailing list arrangement
> d) j-c is very well supervised
> e) committed coders are in charge of their components
>
> My mail system would undoutably be better off with multiple lists. But
> j-c
> may suffer. This is a dilema. It would be nice if there was a clear
> division
> into two or three that could occur, but finding it causes problems.
i'd be very, very unhappy to see any more sub-projects with split
mailing lists at jakarta. jakarta is moving towards a more healthy
position but it's going to take time. split mailing lists are part of
the problem. we've got enough problems at jakarta without making any
more.
so, i'd like to try to encourage people to think about whether there's
enough synergy to move some products (at least) here to apache commons.
the folks already here are all library builders (even though in other
languages) so there's at least one area of common interest. some
jakarta-commons products share similar goals. the ASF also contains
some of the original framers of RFCs that some commons products are
implementing.
in terms of synergy in the community, i'd say that it's early enough in
the process (of formation) for the apache commons community to be
influenced by any product communities who want to move. there's
unlikely to be too much repressive beurocracy here (almost certainly
less than the jakarta pmc is likely to be forced to institute - jakarta
is now too big and too diverse.)
it seems to me that people who haven't been around jakarta for too long
tend to forget that when jakarta was formed, jakarta was very
frequently, strongly (and unfairly) critisized for living off the
reputation of the apache httpd server. in the end, the apache way (and
the quality of the jakarta code and the jakarta people) prevailed. it
might seem strange now but it's very possible that apache commons might
become (in a few years time) as reknown as a producers of library code
as jakarta is reknown as a producer of server-side code. but only if
those people who help to make jakarta-commons such a hothouse decide to
move here.
IMHO the jakarta pmc is going to have to get a lot tougher and it's
going to become a little more painful for committers than it's been
before. we're going to have to take even more seriously the issues of
scope and oversight. this means that some stuff that (in other
circumstances) would be really cool might not be able to happen at
jakarta. this doesn't mean that it shouldn't happen elsewhere in
apache.
- robert
Divinding J-C
Posted by Stephen Colebourne <sc...@btopenworld.com>.
> My mail system would undoutably be better off with multiple lists. But j-c
> may suffer. This is a dilema. It would be nice if there was a clear
division
> into two or three that could occur, but finding it causes problems.
>
There MAY be potential to divide j-c into two separate Jakarta projects,
'core' and 'utility'. The division I see based on level in an (example)
application stack:
User application
Struts etc.
Utility
Core
Thus utility depends on core jar files, but not vice versa. In fact, core
jars generally depend on nothing but the JDK. The utility level components
also tend to have more 'religion' about them (ie. you have to take more time
to learn them, and to fit into their ways).
This kind of division would give j-c more sensible traffic on the lists,
hence more sensible and clear oversight. Because the division is only into
two, there should be enough people about to populate each sufficiently.
Well, its an idea (and probably should go to j-c list ;-)
Stephen
----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: <ge...@commons.apache.org>
Sent: Thursday, November 13, 2003 1:05 AM
Subject: Re: J-C oversight (was: Benefits of Apache Commons)
> From: "robert burrell donkin" <rd...@apache.org>
> > jakarta-commons is high traffic but the worries about scalability are
> > not to do with supervision but whether normal developers can continue
> > to be attracted.
>
> I've been quiet for a while, but I wanted to agree with this last
statement.
> Its not about supervision in j-c, but keeping attracting new ideas and
> committers.
>
> I would suggest
> a) the j-c mailing list is very high traffic
> b) some newcomers/contributers are definitely being put off by this
> c) the ability for j-c to accept new components must eventually be limited
> by the one mailing list arrangement
> d) j-c is very well supervised
> e) committed coders are in charge of their components
>
> Stephen
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
Re: J-C oversight (was: Benefits of Apache Commons)
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "robert burrell donkin" <rd...@apache.org>
> jakarta-commons is high traffic but the worries about scalability are
> not to do with supervision but whether normal developers can continue
> to be attracted.
I've been quiet for a while, but I wanted to agree with this last statement.
Its not about supervision in j-c, but keeping attracting new ideas and
committers.
I would suggest
a) the j-c mailing list is very high traffic
b) some newcomers/contributers are definitely being put off by this
c) the ability for j-c to accept new components must eventually be limited
by the one mailing list arrangement
d) j-c is very well supervised
e) committed coders are in charge of their components
My mail system would undoutably be better off with multiple lists. But j-c
may suffer. This is a dilema. It would be nice if there was a clear division
into two or three that could occur, but finding it causes problems.
Stephen
Re: J-C oversight
Posted by Sam Ruby <ru...@apache.org>.
robert burrell donkin wrote:
> On 12 Nov 2003, at 11:21, Greg Stein wrote:
>
> <snip>
>
>> The J-C development list is apparently so trafficked that individuals
>> cannot really keep up with it. To retain proper oversight, that must be
>> broken down and partitioned into manageable chunks. Quite doable. But the
>> PMC is still responsible, as a whole, for every chunk that is
>> produced. No
>> matter how you might partition the *mailing lists*, that total amount of
>> traffic is still present. Then throw in all the other Jakarta traffic.
>> Then try to say that a group of a couple dozen people are directing *ALL*
>> of that effort. It just isn't believable.
>
>
> i'm concerned about this kind of criticism (which has very often been
> repeated). it doesn't really tally with the opinions expressed by the
> jakarta pmc. jakarta-commons has more ASF members and jakarta pmc
> members subscribed than any other jakarta sub-project. many of these
> people look at every message that is sent to the list.
>
> one mailing list is the solution not the problem. it forces everyone
> close together and makes it impossible to keep anything a secret for
> very long. in the past, the problems have arisen with umbrella
> sub-projects. these develop their own communities and their own rules of
> behaviour. they spawn new mailing lists and sub-sub-projects dividing
> the community and preventing effective oversight.
>
> what worries myself is not the oversight of the jakarta-commons. it's
> turbine. i don't believe that umbrella sub-projects can be effectively
> supervised.
>
> please greg, listen to what we've been saying over the last few months
> about this issue. the consensus on the jakarta pmc is that
> jakarta-commons works very well and is well supervised. we are worried
> about supervision - very worried - but not about worried at all about
> jakarta-commons.
>
> jakarta-commons is high traffic but the worries about scalability are
> not to do with supervision but whether normal developers can continue to
> be attracted.
>
> - robert
I concur with this assessment.
- Sam Ruby
Re: J-C oversight (was: Benefits of Apache Commons)
Posted by robert burrell donkin <rd...@apache.org>.
On 12 Nov 2003, at 11:21, Greg Stein wrote:
<snip>
> The J-C development list is apparently so trafficked that individuals
> cannot really keep up with it. To retain proper oversight, that must be
> broken down and partitioned into manageable chunks. Quite doable. But
> the
> PMC is still responsible, as a whole, for every chunk that is
> produced. No
> matter how you might partition the *mailing lists*, that total amount
> of
> traffic is still present. Then throw in all the other Jakarta traffic.
> Then try to say that a group of a couple dozen people are directing
> *ALL*
> of that effort. It just isn't believable.
i'm concerned about this kind of criticism (which has very often been
repeated). it doesn't really tally with the opinions expressed by the
jakarta pmc. jakarta-commons has more ASF members and jakarta pmc
members subscribed than any other jakarta sub-project. many of these
people look at every message that is sent to the list.
one mailing list is the solution not the problem. it forces everyone
close together and makes it impossible to keep anything a secret for
very long. in the past, the problems have arisen with umbrella
sub-projects. these develop their own communities and their own rules
of behaviour. they spawn new mailing lists and sub-sub-projects
dividing the community and preventing effective oversight.
what worries myself is not the oversight of the jakarta-commons. it's
turbine. i don't believe that umbrella sub-projects can be effectively
supervised.
please greg, listen to what we've been saying over the last few months
about this issue. the consensus on the jakarta pmc is that
jakarta-commons works very well and is well supervised. we are worried
about supervision - very worried - but not about worried at all about
jakarta-commons.
jakarta-commons is high traffic but the worries about scalability are
not to do with supervision but whether normal developers can continue
to be attracted.
- robert
Re: J-C oversight (was: Benefits of Apache Commons)
Posted by Rodney Waldhoff <rw...@apache.org>.
On Wed, 12 Nov 2003, Greg Stein wrote:
> On Tue, Nov 11, 2003 at 03:41:25PM -0800, Rodney Waldhoff wrote:
> > On Mon, 10 Nov 2003, Greg Stein wrote:
> > > If you want to fix the oversight in J-C, then do so. Personally, I don't
> > > believe it is possible, for the reasons that Robert has already described.
> > > But I certainly won't stop you from trying.
> >
> > Greg, can you expand upon what you see as the "oversight" problem in
> > Jakarta-Commons? I'm not sure what you mean by that.
>
> This feels like it is getting off-topic, although there is still some
> relevance since A-C is quite similar to J-C.
Thanks for taking the time to respond here. I disagree with some
(although not all) of these assertions, but since as you note this is
beginning to push to bounds of on-topic discussion, I won't try to debate
them here.
I do have one question regarding this:
> Take things like Hivemind, Jelly, and whatstheotherone. In the list that
> Stephen posted recently, he labeled these as "should be TLPs." What the
> *heck* are they doing way down in J-C if they are TLP material? How could
> Hivemind grow to become a framework while sitting in Commons without
> anybody really saying, "wow. that needs to move."
Just to make sure I undestand you, is your concern here that these
projects are (a) out of scope for jakarta (b) out of scope of jakarta
commons or (c) too large for jakarta commons, or (d) some combination of
the above?
>
> Cheers,
> -g
>
- Rod <http://radio.weblogs.com/0122027/>
Re: J-C oversight
Posted by Sam Ruby <ru...@apache.org>.
Greg Stein wrote:
>
> The information overload is very well characterized by a reference
> somebody made recently to a Jakarta report to the board. See Attachment D
> in the March minutes:
>
> http://www.apache.org/foundation/records/minutes/2003/board_minutes_2003_03_19.txt
>
> The most recent report defers much of the report to the Jakarta
> newsletter. It doesn't summarize the state for the Board, and it doesn't
> provide any insight into community issues, interactions, legal issues, or
> forward thoughts of the PMC. We have this *massive* amount of code and a
> *huge* community, and the PMC is not able to effectively report on what is
> happening.
>
> Is it just me? Maybe. But as a Director, I'm supposed to be able to review
> this stuff and know whether Jakarta is going well/poorly. I have never
> felt that I have enough information to really know that. And the scary
> part is that I'm one of the more informed Directors -- I'm subscribed to
> the Jakarta PMC list (along with one or two other Directors). The rest?
> Scrappy info.
If I recall correctly, this report was approved as submitted. You
certainly could have raised issues at the time, but instead it was
accepted by unamimous consent... only to be brought up later as an issue
on the general@commons mailing list.
I personally think that having the information online, continuously
updated, and available for review to all is a good thing.
One way or another, the root issue is information overload. One could
certainly immagine a four paragraph update for each row in the following:
http://gump.covalent.net/log/xref.html
- Sam Ruby
Re: J-C oversight (was: Benefits of Apache Commons)
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 12 Nov 2003, Greg Stein wrote:
> Take things like Hivemind, Jelly, and whatstheotherone. In the list that
> Stephen posted recently, he labeled these as "should be TLPs." What the
> *heck* are they doing way down in J-C if they are TLP material? How could
> Hivemind grow to become a framework while sitting in Commons without
> anybody really saying, "wow. that needs to move."
Hivemind and Math are still in the sandbox, so now is the correct time for
people to be saying 'wow. that needs to move.'. Jelly is in Commons
'proper', but has not yet released so now is also the right time for that.
Hivemind are putting together a proposal to be an SLP [what is the term
for this, S for Second] within Jakarta.
> There is a "sandbox" which is labeled as some kind of playground for ASF
> committers to monkey in. That is wrong.
It is a part of the Jakarta Commons Charter that it is an incubation area.
> *Anything* in the ASF CVS
> repository is owned by the ASF and requires the *SAME* oversight as larger
> projects like Tomcat, httpd, or Cocoon. Label the sandbox all you want as
No argument here. Being watchful over legalities in the sandbox is an
essential role of the J-Commons community.
> "unofficial" or "being worked on until it 'graduates'" or whatever. The
> simple fact is that the mechanism encourages single committers to go wild
> under the banner of the ASF.
It is less managed than Incubation and I agree that as Incubator matures
the J-Commons-Sandbox needs to get more restrictive to be more negative
towards larger concepts. I'm not sure Jelly or Math would have been
developed elsewhere under such a concept, but maybe Hivemind would have
been developed under the incubator rather than in sandbox. Effectively as
Incubator matures, the sandbox will become more and more a back door.
> The J-C development list is apparently so trafficked that individuals
> cannot really keep up with it.
I keep up happily with the parts I consider myself involved in. I've no
interest in Jelly/Hivemind/some of the others and so filter them out then
delete later.
> To retain proper oversight, that must be
> broken down and partitioned into manageable chunks. Quite doable. But the
Agreed. Even knowing that every component on the J-C list has a PMC member
is not enough to ensure that it has oversight. What if there is only one
member paying attention to one component and that person is on vacation,
or focusing attention elsewhere. Even if there were 4 out of 5 PMC'ers on
the component, how do you ensure those 4 are paying attention to what the
other 1 is doing.
> PMC is still responsible, as a whole, for every chunk that is produced. No
> matter how you might partition the *mailing lists*, that total amount of
> traffic is still present. Then throw in all the other Jakarta traffic.
> Then try to say that a group of a couple dozen people are directing *ALL*
> of that effort. It just isn't believable.
>
> The problem is that it has to be beyond believable. We have to be able to
> stand up in a court and say "the PMC told those committers to do that."
> There can't be a question about it.
"Someone on the PMC was aware of it and had the opportunity to veto it" is
where I would currently say we are. Though the veto is after the action.
> Putting "one member from each (sub-)sub-project onto the PMC" is getting
> there, but that still feels like the individual, rather than the PMC, is
> managing the project.
It seems like a typical people problem. There are too many people for the
shallow management structure that ASF like, there is also a small amount
of energy for management in a structure like ASF. The only solution so far
has been to remove people by creating more TLPs.
Another solution would be to instill more bureacracy and internal reports
inside Jakarta that filter upwards to be summarised to board. Effectively
turning the newsletter into a charter-mandated report tree.
> Is it just me? Maybe. But as a Director, I'm supposed to be able to review
Only in that you're the one who has to have the complete oversight or
trust in oversight.
> All that said, I can also state that it could be fairly said some of the
> other PMCs might not be providing enough information either. In fact, that
> has been raised here, "well, yah, but are you getting reports from the
> httpd docs group?" Otherwise stated as, "but they suck, so we can too!" :-)
> My point is that I may be unfairly focused on Jakarta. But I get to do
I agree that it needs the focus as the biggest blind-side to you. The
biggest part of the 'reports from httpd docs group' question is really 'so
show us how it's meant to be'.
> of the projects under it. And J-C is one of those, and is arguably one the
> *most* active projects within Jakarta, yet it almost has an extra "layer"
> between it and the PMC -- it effectively has its own charter and rules and
> other policies. There have been threats of a J-C "sub PMC" which have
> (thankfully) been shot down.
The bullets missed ;) PMC members who work in J-Commons are going to
become a de-facto sub-committee I suspect. In the same way that 2
committers on Jakarta Turbine [random name] are effectively the
sub-committee there.
Hen
Re: J-C oversight (was: Benefits of Apache Commons)
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, November 12, 2003, at 06:21 AM, Greg Stein wrote:
>
>
> All that said, I can also state that it could be fairly said some of
> the
> other PMCs might not be providing enough information either. In fact,
> that
> has been raised here, "well, yah, but are you getting reports from the
> httpd docs group?" Otherwise stated as, "but they suck, so we can
> too!" :-)
I think you are misrepresenting me again. I'll assume it isn't
deliberate. :)
My point was only in relation to your statement that the board didn't
receive a j-c report from the Jakarta PMC. To that end, I asked if
other Apache projects gave individual reports, and used 'docs' as an
example. I had no belief that the board got such a report, nor that
one was really required. I'm assuming httpd docs are just fine.
And never will I claim that we can suck because someone else does -
both have to be cleaned up if both suck.
geir
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
J-C oversight (was: Benefits of Apache Commons)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 11, 2003 at 03:41:25PM -0800, Rodney Waldhoff wrote:
> On Mon, 10 Nov 2003, Greg Stein wrote:
> > If you want to fix the oversight in J-C, then do so. Personally, I don't
> > believe it is possible, for the reasons that Robert has already described.
> > But I certainly won't stop you from trying.
>
> Greg, can you expand upon what you see as the "oversight" problem in
> Jakarta-Commons? I'm not sure what you mean by that.
This feels like it is getting off-topic, although there is still some
relevance since A-C is quite similar to J-C.
Take things like Hivemind, Jelly, and whatstheotherone. In the list that
Stephen posted recently, he labeled these as "should be TLPs." What the
*heck* are they doing way down in J-C if they are TLP material? How could
Hivemind grow to become a framework while sitting in Commons without
anybody really saying, "wow. that needs to move."
There is a "sandbox" which is labeled as some kind of playground for ASF
committers to monkey in. That is wrong. *Anything* in the ASF CVS
repository is owned by the ASF and requires the *SAME* oversight as larger
projects like Tomcat, httpd, or Cocoon. Label the sandbox all you want as
"unofficial" or "being worked on until it 'graduates'" or whatever. The
simple fact is that the mechanism encourages single committers to go wild
under the banner of the ASF.
The J-C development list is apparently so trafficked that individuals
cannot really keep up with it. To retain proper oversight, that must be
broken down and partitioned into manageable chunks. Quite doable. But the
PMC is still responsible, as a whole, for every chunk that is produced. No
matter how you might partition the *mailing lists*, that total amount of
traffic is still present. Then throw in all the other Jakarta traffic.
Then try to say that a group of a couple dozen people are directing *ALL*
of that effort. It just isn't believable.
The problem is that it has to be beyond believable. We have to be able to
stand up in a court and say "the PMC told those committers to do that."
There can't be a question about it.
Putting "one member from each (sub-)sub-project onto the PMC" is getting
there, but that still feels like the individual, rather than the PMC, is
managing the project.
The information overload is very well characterized by a reference
somebody made recently to a Jakarta report to the board. See Attachment D
in the March minutes:
http://www.apache.org/foundation/records/minutes/2003/board_minutes_2003_03_19.txt
The most recent report defers much of the report to the Jakarta
newsletter. It doesn't summarize the state for the Board, and it doesn't
provide any insight into community issues, interactions, legal issues, or
forward thoughts of the PMC. We have this *massive* amount of code and a
*huge* community, and the PMC is not able to effectively report on what is
happening.
Is it just me? Maybe. But as a Director, I'm supposed to be able to review
this stuff and know whether Jakarta is going well/poorly. I have never
felt that I have enough information to really know that. And the scary
part is that I'm one of the more informed Directors -- I'm subscribed to
the Jakarta PMC list (along with one or two other Directors). The rest?
Scrappy info.
All that said, I can also state that it could be fairly said some of the
other PMCs might not be providing enough information either. In fact, that
has been raised here, "well, yah, but are you getting reports from the
httpd docs group?" Otherwise stated as, "but they suck, so we can too!" :-)
My point is that I may be unfairly focused on Jakarta. But I get to do
that; I'm just me, not the Board, and I get to have an opinion on where I
think the sore spot is. (and have no fear, I've got criticisms for most of
the PMCs :-) Can any of the PMCs operate Right And True(tm) ? Dunno, but
I think that the Jakarta PMC has the lowest hope because of the sheer size
of the projects under it. And J-C is one of those, and is arguably one the
*most* active projects within Jakarta, yet it almost has an extra "layer"
between it and the PMC -- it effectively has its own charter and rules and
other policies. There have been threats of a J-C "sub PMC" which have
(thankfully) been shot down.
I'll leave the comparison/contrast against A-C to others :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Nov 15, 2003 at 10:27:56AM -0800, Greg Stein wrote:
> On Sat, Nov 15, 2003 at 03:51:45PM +0000, robert burrell donkin wrote:
> > On 11 Nov 2003, at 23:41, Rodney Waldhoff wrote:
> >...
> > > Greg, can you expand upon what you see as the "oversight" problem in
> > > Jakarta-Commons? I'm not sure what you mean by that.
> >
> > i don't believe that there is any problem overseeing jakarta-commons.
> > jakarta-commons has been unfairly accused before (during the problems
> > that were happening in avalon). please tell us why you think there is a
> > problem.
>
> I responded already under a different subject line.
Under the subject "J-C Oversight". And I note that you responded to that
thread twice already, Robert :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Greg Stein <gs...@lyra.org>.
On Sat, Nov 15, 2003 at 03:51:45PM +0000, robert burrell donkin wrote:
> On 11 Nov 2003, at 23:41, Rodney Waldhoff wrote:
>...
> > Greg, can you expand upon what you see as the "oversight" problem in
> > Jakarta-Commons? I'm not sure what you mean by that.
>
> i don't believe that there is any problem overseeing jakarta-commons.
> jakarta-commons has been unfairly accused before (during the problems
> that were happening in avalon). please tell us why you think there is a
> problem.
I responded already under a different subject line.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by robert burrell donkin <rd...@apache.org>.
On 11 Nov 2003, at 23:41, Rodney Waldhoff wrote:
> On Mon, 10 Nov 2003, Greg Stein wrote:
>
>> If you want to fix the oversight in J-C, then do so. Personally, I
>> don't
>> believe it is possible, for the reasons that Robert has already
>> described.
>> But I certainly won't stop you from trying.
>
> Greg, can you expand upon what you see as the "oversight" problem in
> Jakarta-Commons? I'm not sure what you mean by that.
i don't believe that there is any problem overseeing jakarta-commons.
jakarta-commons has been unfairly accused before (during the problems
that were happening in avalon). please tell us why you think there is a
problem.
- robert
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Rodney Waldhoff <rw...@apache.org>.
On Mon, 10 Nov 2003, Greg Stein wrote:
> If you want to fix the oversight in J-C, then do so. Personally, I don't
> believe it is possible, for the reasons that Robert has already described.
> But I certainly won't stop you from trying.
Greg, can you expand upon what you see as the "oversight" problem in
Jakarta-Commons? I'm not sure what you mean by that.
> Cheers,
> -g
>
>
--
- Rod <http://radio.weblogs.com/0122027/>
Re: Benefits of Apache Commons
Posted by robert burrell donkin <rd...@apache.org>.
On 12 Nov 2003, at 12:46, Geir Magnusson Jr. wrote:
> On Wednesday, November 12, 2003, at 06:36 AM, Greg Stein wrote:
<snip>
>> To me, I read the resistance to A-C and some of the responses as
>> feeling
>> threatened by a loss of community, self-rule, etc. So... that's how I
>> read
>> it; if that doesn't represent your thinking, then I apologize, and
>> will
>> blame email as an imperfect medium. What may simply be "devil's
>> advocate"
>> discussion or similar can easily be construed as reading a position or
>> belief, which can be quite incorrect. And, of course, the easiest way
>> to
>> correct it is to call out the issue as you did :-)
>
> I think that 'loss of community' isn't a threat - it's a mistake, but
> that's just my opinion. And 'self-rule' wouldn't change - the people
> that should be in charge, the committers, will probably be in charge
> in A-C. So no real change from those perspectives.
>
> I think I'm just confused. There is a 'Jakarta must die' flavor to
> all of this. (That's a quote, btw). Call it paranoia on my part, but
> when I see Robert, who is usually very factual and correct, on the J-C
> list saying things like :
>
> "commons-maths will still be part of jakarta-commons :)
>
> it'll only be managed by the apache-commons pmc.
>
> best of both worlds :)"
>
> http://marc.theaimsgroup.com/?l=jakarta-commons-
> dev&m=106841721301207&w=2
as i understood it, this is what the flatteners (such as stephano) were
proposing: projects can be part of the jakarta community - manifest by
links from the main jakarta web site - without having to be managed by
the jakarta pmc at least from the perspective of users. from the
perspective of committers (of course) the product would be part of
another project.
> I'm just simply baffled by what's going on. How could it be that a
> J-C project is managed by A-C's PMC? Is that something the board has
> mandated? That A-C will managed codebases in other Apache projects?
as i understood it, flattening was the official way forward.
if flattening is to progress further then IMHO either jakarta will have
to start throwing sub-projects out or the kind of vision outlined by
stephano (and the other flatteners) whereby products can be in jakarta
from the perspective of the user but in another project from the
perspective of the ASF is needed.
jakarta has a good reputation in the java community and is probably now
better known that apache within that community. losing the benefit of
that reputation is something that many sub-projects seems to fear.
- robert
Re: Benefits of Apache Commons
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Wednesday, November 12, 2003, at 06:36 AM, Greg Stein wrote:
> On Tue, Nov 11, 2003 at 05:24:59AM -0800, Rodney Waldhoff wrote:
>> On Mon, 10 Nov 2003, Greg Stein wrote:
>> ...
>>> Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You
>>> don't
>>> have to. But some others do, and it appears that some J-C components
>>> will
>>> move. Why is that so threatening?
>>
>> On the contrary, I think apache-commons has several things going for
>> it,
>> and I'd very much like to see the project, or more generally, its
>> mission
>> of creating reusable library code under the ASL, succeed. Frankly,
>> I'm a
>> bit insulted you'd characterize this interest as feeling "threatened"
>> by
>> the possibility, and I'm disappointed that you'd respond to any
>> difference
>> of opinion about how to best accomplish that mission by with comments
>> along the lines of "and if you disagree, then go away".
>
> I don't want you guys to "go away". Quite the contrary. I'd prefer if
> you
> offered constructive criticism, assistance, and insight. But to be
> honest,
> a lot of what I have seen is "but why? J-C does this already. let's
> just
> promote that instead." or "why should they give up their community?" or
> "svn creates barriers" or ...
>
> There has been very little, "this is how J-C operates, and to make them
> feel at home in A-C, we should do X."
>
> To be honest, Rodney: yes, I may have lumped you in unfairly with Geir,
> whose positions are very much more "J-C does this right. why should
> anyone
> bother with A-C?" But my response was built from an overall impression,
> which is that I'm not seeing "we can fix things <this> way".
I guess my problem is that I don't yet buy into A-C as a forgone
conclusion as the solution to J-Cs problems, when there's incredible
potential to fix what is deemed wrong with J-C. I do see value in the
language specific community of J-C, given the richness of interaction
due to binary interoperability. Also, I obviously think that the
'commons' notion is a good idea. Math *is* a good example of a
candidate to move to A-C is there's interest in doing math in some
other language for speed, and then the j-c math would use JNI to get to
the fast libraries in A-C. But there's a few ways to skin that cat too.
It appears to me that A-C is being bootstrapped from top down rather
than bottom up. J-C was a bottom-up bootstrap put together by a bunch
of us in jakarta who noticed a problem (lots of duplicated utility code
in the jakarta sub-projects) and went about solving it. It was a
community solution - many, many jakarta members debated [seemingly
endlessly] about our charter, proposed it to the PMC of Jakarta, and
got it going. It's been a runaway success. (Which is the problem - you
have a previous post where you point out the obvious problems, like the
single mail list, etc)
And please don't misrepresent my positions - I don't wonder why anyone
should "bother" with A-C - I just don't see anyone naturally doing it
besides you and Justin w/ surf. It sounds like A-C is the proper
solution for serf if it didn't fit in httpd, but wonder why there
hasn't been any natural migration of other code from Apache projects.
In a way, A-C is what I hoped DB could be, language-neutral (or
any-language) tools and utilities, just w/o the db focus. And to that
end, I'm surprised too that there wasn't more that moved into db. I
thought that there would be a bunch of ETL-ish things in languages
other than Java that would want to find a home there, but there hasn't
been any interest. I guess either because of poor advertising, or
established projects don't see the value of moving.
>
> To me, I read the resistance to A-C and some of the responses as
> feeling
> threatened by a loss of community, self-rule, etc. So... that's how I
> read
> it; if that doesn't represent your thinking, then I apologize, and will
> blame email as an imperfect medium. What may simply be "devil's
> advocate"
> discussion or similar can easily be construed as reading a position or
> belief, which can be quite incorrect. And, of course, the easiest way
> to
> correct it is to call out the issue as you did :-)
I think that 'loss of community' isn't a threat - it's a mistake, but
that's just my opinion. And 'self-rule' wouldn't change - the people
that should be in charge, the committers, will probably be in charge in
A-C. So no real change from those perspectives.
I think I'm just confused. There is a 'Jakarta must die' flavor to all
of this. (That's a quote, btw). Call it paranoia on my part, but when
I see Robert, who is usually very factual and correct, on the J-C list
saying things like :
"commons-maths will still be part of jakarta-commons :)
it'll only be managed by the apache-commons pmc.
best of both worlds :)"
http://marc.theaimsgroup.com/?l=jakarta-commons-
dev&m=106841721301207&w=2
I'm just simply baffled by what's going on. How could it be that a J-C
project is managed by A-C's PMC? Is that something the board has
mandated? That A-C will managed codebases in other Apache projects?
>
>> Not to put to fine a point on it, but if I were "threatened" by the
>> possibility of jakarta-commons components moving to apache-commons,
>> then I
>> probably wouldn't be offering suggestions about how best to encourage
>> j-c
>> components to move to a-c, as you see me doing at
>> <http://article.gmane.org/gmane.comp.apache.commons.general/151> and
>> <http://article.gmane.org/gmane.comp.apache.commons.general/158>, to
>> name
>> two examples.
>
> And re-reading those two posts also leads me to say, "hunh. there
> *have*
> been nuggets of 'here is info about J-C'". Mebbe too thick-headed to
> see
> them :-). I might suggest that the answer is to simply start asking
> J-C
> components if they want to move. If they say "yes", then fine. If they
> say
> "no", then we ask "why?". That provides very concrete info rather than
> continual discussion and theorizing...
The math component is doing that, and there are some interesting
possibilities.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Nov 11, 2003 at 05:24:59AM -0800, Rodney Waldhoff wrote:
> On Mon, 10 Nov 2003, Greg Stein wrote:
>...
> > Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You don't
> > have to. But some others do, and it appears that some J-C components will
> > move. Why is that so threatening?
>
> On the contrary, I think apache-commons has several things going for it,
> and I'd very much like to see the project, or more generally, its mission
> of creating reusable library code under the ASL, succeed. Frankly, I'm a
> bit insulted you'd characterize this interest as feeling "threatened" by
> the possibility, and I'm disappointed that you'd respond to any difference
> of opinion about how to best accomplish that mission by with comments
> along the lines of "and if you disagree, then go away".
I don't want you guys to "go away". Quite the contrary. I'd prefer if you
offered constructive criticism, assistance, and insight. But to be honest,
a lot of what I have seen is "but why? J-C does this already. let's just
promote that instead." or "why should they give up their community?" or
"svn creates barriers" or ...
There has been very little, "this is how J-C operates, and to make them
feel at home in A-C, we should do X."
To be honest, Rodney: yes, I may have lumped you in unfairly with Geir,
whose positions are very much more "J-C does this right. why should anyone
bother with A-C?" But my response was built from an overall impression,
which is that I'm not seeing "we can fix things <this> way".
To me, I read the resistance to A-C and some of the responses as feeling
threatened by a loss of community, self-rule, etc. So... that's how I read
it; if that doesn't represent your thinking, then I apologize, and will
blame email as an imperfect medium. What may simply be "devil's advocate"
discussion or similar can easily be construed as reading a position or
belief, which can be quite incorrect. And, of course, the easiest way to
correct it is to call out the issue as you did :-)
> Not to put to fine a point on it, but if I were "threatened" by the
> possibility of jakarta-commons components moving to apache-commons, then I
> probably wouldn't be offering suggestions about how best to encourage j-c
> components to move to a-c, as you see me doing at
> <http://article.gmane.org/gmane.comp.apache.commons.general/151> and
> <http://article.gmane.org/gmane.comp.apache.commons.general/158>, to name
> two examples.
And re-reading those two posts also leads me to say, "hunh. there *have*
been nuggets of 'here is info about J-C'". Mebbe too thick-headed to see
them :-). I might suggest that the answer is to simply start asking J-C
components if they want to move. If they say "yes", then fine. If they say
"no", then we ask "why?". That provides very concrete info rather than
continual discussion and theorizing...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Rodney Waldhoff <rw...@apache.org>.
On Mon, 10 Nov 2003, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 07:01:18PM -0500, Geir Magnusson Jr. wrote:
> > On Monday, November 10, 2003, at 06:32 PM, Greg Stein wrote:
> > > On Mon, Nov 10, 2003 at 05:33:30PM -0500, Geir Magnusson Jr. wrote:
> > >> ...
> > >> Why not just free j-c to be a TLP if it wants to?
> > >
> > > Why would the board be inclined to create a *second* Commons project
> > > when the first one they created should be sufficient?
> >
> > The second one has well-known and widely used code and years of
> > established community?
>
> And the Board would simply respond with something like, "well, why doesn't
> that community operate as part of the A-C TLP?"
>
>
> Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You don't
> have to. But some others do, and it appears that some J-C components will
> move. Why is that so threatening?
On the contrary, I think apache-commons has several things going for it,
and I'd very much like to see the project, or more generally, its mission
of creating reusable library code under the ASL, succeed. Frankly, I'm a
bit insulted you'd characterize this interest as feeling "threatened" by
the possibility, and I'm disappointed that you'd respond to any difference
of opinion about how to best accomplish that mission by with comments
along the lines of "and if you disagree, then go away".
Not to put to fine a point on it, but if I were "threatened" by the
possibility of jakarta-commons components moving to apache-commons, then I
probably wouldn't be offering suggestions about how best to encourage j-c
components to move to a-c, as you see me doing at
<http://article.gmane.org/gmane.comp.apache.commons.general/151> and
<http://article.gmane.org/gmane.comp.apache.commons.general/158>, to name
two examples.
> If you want to fix the oversight in J-C, then do so. Personally, I don't
> believe it is possible, for the reasons that Robert has already described.
> But I certainly won't stop you from trying.
>
> Cheers,
> -g
- Rod <http://radio.weblogs.com/0122027/>
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 07:01:18PM -0500, Geir Magnusson Jr. wrote:
> > On Monday, November 10, 2003, at 06:32 PM, Greg Stein wrote:
> > > On Mon, Nov 10, 2003 at 05:33:30PM -0500, Geir Magnusson Jr. wrote:
> > >> ...
> > >> Why not just free j-c to be a TLP if it wants to?
> > >
> > > Why would the board be inclined to create a *second* Commons project
> > > when the first one they created should be sufficient?
> >
> > The second one has well-known and widely used code and years of
> > established community?
>
> And the Board would simply respond with something like, "well, why doesn't
> that community operate as part of the A-C TLP?"
>
>
> Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You don't
> have to. But some others do, and it appears that some J-C components will
> move. Why is that so threatening?
So much to reply to and so hard to be excited.
The only reasoon why the board should accept J-C being promoted is that up
until now the board has been pushing for J projects that want to become
TLP to stand up and be counted.
This holds for everything but J-C?
> If you want to fix the oversight in J-C, then do so. Personally, I don't
> believe it is possible, for the reasons that Robert has already described.
> But I certainly won't stop you from trying.
I believe they are utterly fixable.
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 07:15 PM, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 07:01:18PM -0500, Geir Magnusson Jr. wrote:
>> On Monday, November 10, 2003, at 06:32 PM, Greg Stein wrote:
>>> On Mon, Nov 10, 2003 at 05:33:30PM -0500, Geir Magnusson Jr. wrote:
>>>> ...
>>>> Why not just free j-c to be a TLP if it wants to?
>>>
>>> Why would the board be inclined to create a *second* Commons project
>>> when the first one they created should be sufficient?
>>
>> The second one has well-known and widely used code and years of
>> established community?
>
> And the Board would simply respond with something like, "well, why
> doesn't
> that community operate as part of the A-C TLP?"
And maybe they'd respond by inviting the serf codebase and you and
Justin to join a j-c-led TLP :)
>
> Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You
> don't
> have to. But some others do, and it appears that some J-C components
> will
> move. Why is that so threatening?
I guess I don't get the point. Having J-C inspire the A-C effort is
very complimentary - as a J-C founder, I take it as a compliment,
especially since J-C was created by the committers of Jakarta
organizing themselves to solve a problem rather than by board or PMC
edict. Maybe that's what bothers me - that instead of a mob of Apache
committers getting together and petitioning the board to create a
project where they could come together, it seems to be happening the
other way - the board created it, hoping they will come.
It just seems like if the interest is ensuring proper oversight of what
is a vibrant and prosperous community, getting it to break apart by
fragmentation into A-C seems counterproductive.
>
> If you want to fix the oversight in J-C, then do so. Personally, I
> don't
> believe it is possible, for the reasons that Robert has already
> described.
> But I certainly won't stop you from trying.
Rodney pointed out that there is almost 100% representation on the PMC
by each of the components, due to the good (and healthy) mixing of
participants. I don't understand the repository problem he mentioned,
but I think that the mail list problem is easily solved with, erm, mail
lists.
I don't want to be combative about this -- and if committers of commons
components want to move their code, they have my support FWIW -- but
if umbrella's are the problem, seems like we're just sliding the deck
chairs around.
geir
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 10, 2003 at 07:01:18PM -0500, Geir Magnusson Jr. wrote:
> On Monday, November 10, 2003, at 06:32 PM, Greg Stein wrote:
> > On Mon, Nov 10, 2003 at 05:33:30PM -0500, Geir Magnusson Jr. wrote:
> >> ...
> >> Why not just free j-c to be a TLP if it wants to?
> >
> > Why would the board be inclined to create a *second* Commons project
> > when the first one they created should be sufficient?
>
> The second one has well-known and widely used code and years of
> established community?
And the Board would simply respond with something like, "well, why doesn't
that community operate as part of the A-C TLP?"
Look. Geir, Rodney: if you guys don't believe in A-C, then fine. You don't
have to. But some others do, and it appears that some J-C components will
move. Why is that so threatening?
If you want to fix the oversight in J-C, then do so. Personally, I don't
believe it is possible, for the reasons that Robert has already described.
But I certainly won't stop you from trying.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Rodney Waldhoff <rw...@apache.org>.
On Mon, 10 Nov 2003, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 05:33:30PM -0500, Geir Magnusson Jr. wrote:
> >...
> > Why not just free j-c to be a TLP if it wants to?
>
> Why would the board be inclined to create a *second* Commons project when
> the first one they created should be sufficient?
Because it's what the committers would commit to?
>
> Cheers,
> -g
>
--
- Rod <http://radio.weblogs.com/0122027/>
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 06:32 PM, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 05:33:30PM -0500, Geir Magnusson Jr. wrote:
>> ...
>> Why not just free j-c to be a TLP if it wants to?
>
> Why would the board be inclined to create a *second* Commons project
> when
> the first one they created should be sufficient?
The second one has well-known and widely used code and years of
established community?
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 10, 2003 at 05:33:30PM -0500, Geir Magnusson Jr. wrote:
>...
> Why not just free j-c to be a TLP if it wants to?
Why would the board be inclined to create a *second* Commons project when
the first one they created should be sufficient?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: adding to PMCs (was: Benefits of Apache Commons)
Posted by robert burrell donkin <rd...@apache.org>.
On 11 Nov 2003, at 13:36, Greg Stein wrote:
> On Mon, Nov 10, 2003 at 09:02:09PM -0500, Henri Yandell wrote:
>> On Mon, 10 Nov 2003, robert burrell donkin wrote:
>> ...
>>> whatever the issues, the membership has stayed basically static
>>> whilst
>>> i've been a member even though numerous election votes have been
>>> passed.
>>
>> Really? I thought it had been slowly growing. The problem is that the
>> process for nominating, voting, notifying, accepting, notifying-sam,
>> sam-accepting-subscribe, notifying-board, waiting,
>> sam-adding-to-commiters.txt, someone-adding-to-who-we-are, done, is
>> just
>> too damn long to do 1 at a time.
>
> The "notifying-sam" seems messed up. To me, that says he isn't
> participating in the PMC. If you need to take a specific action to
> notify
> him, then it raises the question (to me) of, "why? shouldn't he have
> already seen that? isn't he already participating in the nominating and
> voting parts?"
IMHO it's not as simple as that. sam is not the real problem.
certainly, when sam was actively driving things strongly forward,
things happened quicker - but sooner or later people on the pmc are
going to have to learn to take responsibility. when sam has left some
slack, no one has stepped forward to take it up.
jakarta doesn't even (at the moment) have a set of election rules that
make sense. people start VOTE threads and then fail to follow them up
(especially myself). i (at least) have been very unclear about the
entire process of informing the board until recently.
there's also the problem that jakarta has grow apart as it's grown
bigger. it's easy to elect lots of good people from the parts of
jakarta which are well policed. but there are some sub-projects where
there are no longer any active faces which are well known generally
within the wider community. this is where we need more supervision (in
the short term) and (in the long term) more pmc members but this is
where it's hardest to elect pmc members.
then there's also the bit about collectively realizing that there's a
problem that needs to be solved. on a positive note, i think that we're
beginning to see some progress on this now. once we get some momentum
and some collective idea about the procedures, things might start to
improve.
- robert
adding to PMCs (was: Benefits of Apache Commons)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 10, 2003 at 09:02:09PM -0500, Henri Yandell wrote:
> On Mon, 10 Nov 2003, robert burrell donkin wrote:
>...
> > whatever the issues, the membership has stayed basically static whilst
> > i've been a member even though numerous election votes have been
> > passed.
>
> Really? I thought it had been slowly growing. The problem is that the
> process for nominating, voting, notifying, accepting, notifying-sam,
> sam-accepting-subscribe, notifying-board, waiting,
> sam-adding-to-commiters.txt, someone-adding-to-who-we-are, done, is just
> too damn long to do 1 at a time.
The "notifying-sam" seems messed up. To me, that says he isn't
participating in the PMC. If you need to take a specific action to notify
him, then it raises the question (to me) of, "why? shouldn't he have
already seen that? isn't he already participating in the nominating and
voting parts?"
The only "long" portions in your process description is the voting and
waiting for the 72 hour period post-board-notification. The rest is
straight-forward and doesn't really need to consume much time.
In any case, that process is basically correct: nominate, vote, notify,
accept, notify-board, wait-for-ack, wait-for-72, add-to-committers.txt.
The bits around the mailing list and whoweare are extraneous to the actual
addition of people to the PMC. (but yes: important to the overall effect)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Jakarta PMC comments (was: Benefits of Apache Commons)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Nov 10, 2003 at 11:18:16PM +0000, robert burrell donkin wrote:
>...
> though i do strongly feel that the criticism of jakarta from the board
> has been unfair,
Woah woah woah. The Board has not made any such criticism. The topic has
never been discussed at a Board meeting. "Greg Stein, ASF Member, and
Directory" has particular issues with how the Jakarta PMC is staffed and
operated. I also have a viewpoint that I don't think proper oversight and
responsibility is being established. I think things occur outside of the
bounds of any Jakarta or J-C charter, and the PMC doesn't really notice or
take corrective actions.
As somebody said, the PMC is responsible for everything, not "some PMC
members are responsible for some parts." Jakarta is too big to make that
possible.
In any case... that is my personal point of view. I wanted to make it
clear that it is *NOT* the position of the Board. At the moment, the Board
has no position -- it is a problem for the PMC to handle. Only if somebody
raises an issue to the Board saying "but the PMC *isn't* handling it",
will the Board care.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by robert burrell donkin <rd...@apache.org>.
On 18 Nov 2003, at 04:40, Geir Magnusson wrote:
> On Nov 17, 2003, at 5:51 PM, robert burrell donkin wrote:
<snip>
>> the jakarta pmc has been criticized by ASF members a *lot* (and over
>> a long period) about it's inability to persuade sub-projects to move
>> to top level status. this isn't going to happen without some advocacy
>> from within the jakarta community.
>
> I guess I'll have to go back and review. I thought the criticism was
> aimed at oversight rather than some desire for structural change.
i think that there are many members who believe that effective
oversight is not possible without structural change. moreover, i
believe that some of these (maybe even a majority) think that unless
the community is willing to undertake these structure changes then (for
reasons of oversight) then the community will need to be reformed from
outside.
> I believe that having umbrella PMCs is a *good* thing, because when
> you break things out, you just move the problem elsewhere, namely the
> board.
personally speaking, i think that this is a very real danger. on the
other hand, the opinions i've heard expressed by the board (abeit in a
personal capacity) seem to indicate to me that they are confident they
can manage things.
> Having an umbrella PMC that is a community of like minded people (Java
> people, XML people, whatever...), then I think that you have a better
> ability to manage because of the common understanding. Of course,
> there still is the issue of how well that PMC operates, but that's not
> what we're talking about here.
i agree up to a point. i think that umbrella pmc are more effective at
generating community spirit. i do think that sometimes that it can be
hard to miss commonalities which exist with apache people working in
different languages. certainly, james committers have noted
commonalities that they didn't recognize before they moved out from
jakarta.
on the other hand, i definitely believe that there's a limit beyond
which they cannot scale effectively. two symptoms that jakarta is now
too big:
1 i'm no longer familiar with all the major developers (those worthy of
election to the pmc)
2 i can no longer subscribe to all the lists at jakarta and read every
mail (whilst staying sane)
i think that the big mistake was allowing umbrella sub-projects. by
this i mean sub-projects with multiple development mailing lists and
sub-sub-projects each working on their own separate products. i don't
think that these can be effectively supervised and lead to community
fragment.
i'm a fan of big development mailing lists. i think that umbrella
projects can work providing that each mailing list has enough active
pmc members subscribed. i don't think that one pmc member (per mailing
list) is anywhere enough (but it's a start). i've argued strongly that
the supervision system we have in the jakarta-commons is effective
(lots of pmc members all subscribed). it has no single point of
failure. my opinions do not seem to be shared by the board, though.
>> if the ASF membership isn't in favour of flattening then i'd hoped
>> that at least one member would have said something.
>
> I'm a member, and speaking for myself, I think that forced flattening
> is a bad idea. I think that voluntary flattening by projects that
> want to do that is a good idea. And to keep my bases covered, I think
> that good PMC oversight is critical here.
pmc oversight is critical anyway :)
i'd say that it's very possible to have a flat (but rotten) pmc. i'm
pretty sure that the board would find out pretty quickly if an umbrella
pmc turned sour - but i'm not so sure about a small flat one.
i don't think that any projects will opt to leave jakarta without at
least some persuasion. this might be the tactics applied by sam to
maven or might just need the possibility to be raised at the right time
(jetspeed and pluto to a new portals.apache.org pmc, probably).
one of the majors reasons why there is resistance to leaving jakarta is
the effect of being listed on the front page of the jakarta web site.
i've tried hard to keep links to projects that have graduated and i'd
be willing to fight to allow sub-projects that leave to become
sub-projects of other pmc's to retain links from either the products
list or a (new) graduated list (i'm think now of jetspeed and pluto).
- robert
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Geir Magnusson <ge...@optonline.net>.
On Nov 17, 2003, at 5:51 PM, robert burrell donkin wrote:
> On 16 Nov 2003, at 19:23, Geir Magnusson Jr. wrote:
>
>> Transcontinental flights are great to catch up on stuff.
>>
>> On Nov 10, 2003, at 6:18 PM, robert burrell donkin wrote:
>
>>> there's also the issue of whether the jakarta-commons community
>>> wants to become top level. there are certainly some who do but i
>>> suspect that most want things to stay as they are. i might be able
>>> to persuade a few components to move (and so gaining some momentum
>>> for a move that way) but persuading the whole of jakarta-commons to
>>> move is certainly beyond me.
>>
>> This is the bit that bugs me. Why should we be persuading anyone to
>> do anything? I'll support and help move people out if they want to
>> move out, I'll support A-C by trying to start/bring non-Java things
>> there if I can and help some other way if I have no code to offer.
>> But I'm not going to start trying to get people to move, especially
>> with weird marketing like "You'll still be part of Jakarta but you
>> won't be!"
>
> the flatteners have presented a vision whereby jakarta would
> (eventually) become just a web site with the currently sub-projects
> managed by themselves. it seems to me that a reasonable description
> (of this condition) is that the project will still be part of jakarta
> but managed by another pmc. "linked from jakarta and retaining jakarta
> website editing rights" would be a more accurate (but longer)
> description.
Interesting experiment.
>
> the jakarta pmc has been criticized by ASF members a *lot* (and over a
> long period) about it's inability to persuade sub-projects to move to
> top level status. this isn't going to happen without some advocacy
> from within the jakarta community.
I guess I'll have to go back and review. I thought the criticism was
aimed at oversight rather than some desire for structural change. I
believe that having umbrella PMCs is a *good* thing, because when you
break things out, you just move the problem elsewhere, namely the
board.
Having an umbrella PMC that is a community of like minded people (Java
people, XML people, whatever...), then I think that you have a better
ability to manage because of the common understanding. Of course,
there still is the issue of how well that PMC operates, but that's not
what we're talking about here.
>
> if the ASF membership isn't in favour of flattening then i'd hoped
> that at least one member would have said something.
I'm a member, and speaking for myself, I think that forced flattening
is a bad idea. I think that voluntary flattening by projects that want
to do that is a good idea. And to keep my bases covered, I think that
good PMC oversight is critical here.
> similarly, if the criticisms don't represent the consensus position
> of the ASF membership then i would have hoped to hear at least one
> dissenting member voice an opinion.
>
I'm that member.
> maybe the ASF members will have a chance to discuss these kinds of
> things at apachecon and come up with some clearer policies...
I wonder how much they do care as a group. Interesting question.
geir
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by robert burrell donkin <rd...@apache.org>.
On 16 Nov 2003, at 19:23, Geir Magnusson Jr. wrote:
> Transcontinental flights are great to catch up on stuff.
>
> On Nov 10, 2003, at 6:18 PM, robert burrell donkin wrote:
>
>>
>> On 10 Nov 2003, at 22:33, Geir Magnusson Jr. wrote:
>>
>>>
>>> On Monday, November 10, 2003, at 05:15 PM, robert burrell donkin
>>> wrote:
>>>
>>>> On 10 Nov 2003, at 21:05, Geir Magnusson Jr. wrote:
>>>>
>>>> <snip>
>>>>
>>>>> Now oversight is another issue entirely, but one that is fixable.
>>>>> If moving projects from j-c to a-c solves the oversight problem,
>>>>> then whatever magic happens when a j-c gets to a-c could easily be
>>>>> applied to jakarta's PMC, right?
>>>>
>>>> i'm not sure that it can.
>>>>
>>>> for a few months now, i've been subscribed to most of the jakarta
>>>> sub-project mailing lists. it started out with the mirroring but i
>>>> stayed as an experiment (partly as a result of the constant
>>>> criticism that the jakarta-pmc receives). last week my email client
>>>> died. i've spent all last week rebuilding a new IMAP server and
>>>> transferring my (very precious) email onto it. i still think that
>>>> it's possible to supervise something as big as jakarta - but only
>>>> just. i don't spend very much time coding now :(
>>>
>>> You aren't the only one that supposed to supervise.
>>
>> we're all suppose to supervise everything - we're certainly
>> responsible for everything. subscription is an interesting experiment
>> and is quite informative.
>
> Before we had representation of every Jakarta subproject on the PMC,
> we organized it so that there were one or more people on the PMC
> assigned to watch subprojects. We don't need that with full project
> rep on the PMC, but you are of course welcome to cover all if you have
> the time. As you are probably starting to realize, that doesn't scale
> :)
that didn't work though, did it?
(i thought that was the point of moving towards a httpd-style pmc.)
>>>> there are major issues about getting more folks on the jakarta pmc.
>>>> at the moment, there are *major* procedure difficulties that are
>>>> preventing our newly elected being officially recognized by the
>>>> board as well as social ones. it is going to take time to reach our
>>>> goal.
>>>
>>> What are the difficulties?
>>
>> some procedural, some social. jakarta doesn't even have a proper rule
>> for deciding when an election succeeds. i've lost one election vote
>> already for a senior apache member. then there's the effort of
>> persuading people to accept the nomination.
>>
>> whatever the issues, the membership has stayed basically static
>> whilst i've been a member even though numerous election votes have
>> been passed.
>
> Well, we can fix that. I think that more process isn't the answer -
> just making it clear and streamlined.
the process was broken but it is being fixed up now.
<snip>
>> there's also the issue of whether the jakarta-commons community wants
>> to become top level. there are certainly some who do but i suspect
>> that most want things to stay as they are. i might be able to
>> persuade a few components to move (and so gaining some momentum for a
>> move that way) but persuading the whole of jakarta-commons to move is
>> certainly beyond me.
>
> This is the bit that bugs me. Why should we be persuading anyone to
> do anything? I'll support and help move people out if they want to
> move out, I'll support A-C by trying to start/bring non-Java things
> there if I can and help some other way if I have no code to offer.
> But I'm not going to start trying to get people to move, especially
> with weird marketing like "You'll still be part of Jakarta but you
> won't be!"
the flatteners have presented a vision whereby jakarta would
(eventually) become just a web site with the currently sub-projects
managed by themselves. it seems to me that a reasonable description (of
this condition) is that the project will still be part of jakarta but
managed by another pmc. "linked from jakarta and retaining jakarta
website editing rights" would be a more accurate (but longer)
description.
the jakarta pmc has been criticized by ASF members a *lot* (and over a
long period) about it's inability to persuade sub-projects to move to
top level status. this isn't going to happen without some advocacy from
within the jakarta community.
if the ASF membership isn't in favour of flattening then i'd hoped that
at least one member would have said something. similarly, if the
criticisms don't represent the consensus position of the ASF membership
then i would have hoped to hear at least one dissenting member voice an
opinion.
maybe the ASF members will have a chance to discuss these kinds of
things at apachecon and come up with some clearer policies...
- robert
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
Transcontinental flights are great to catch up on stuff.
On Nov 10, 2003, at 6:18 PM, robert burrell donkin wrote:
>
> On 10 Nov 2003, at 22:33, Geir Magnusson Jr. wrote:
>
>>
>> On Monday, November 10, 2003, at 05:15 PM, robert burrell donkin
>> wrote:
>>
>>> On 10 Nov 2003, at 21:05, Geir Magnusson Jr. wrote:
>>>
>>> <snip>
>>>
>>>> Now oversight is another issue entirely, but one that is fixable.
>>>> If moving projects from j-c to a-c solves the oversight problem,
>>>> then whatever magic happens when a j-c gets to a-c could easily be
>>>> applied to jakarta's PMC, right?
>>>
>>> i'm not sure that it can.
>>>
>>> for a few months now, i've been subscribed to most of the jakarta
>>> sub-project mailing lists. it started out with the mirroring but i
>>> stayed as an experiment (partly as a result of the constant
>>> criticism that the jakarta-pmc receives). last week my email client
>>> died. i've spent all last week rebuilding a new IMAP server and
>>> transferring my (very precious) email onto it. i still think that
>>> it's possible to supervise something as big as jakarta - but only
>>> just. i don't spend very much time coding now :(
>>
>> You aren't the only one that supposed to supervise.
>
> we're all suppose to supervise everything - we're certainly
> responsible for everything. subscription is an interesting experiment
> and is quite informative.
Before we had representation of every Jakarta subproject on the PMC, we
organized it so that there were one or more people on the PMC assigned
to watch subprojects. We don't need that with full project rep on the
PMC, but you are of course welcome to cover all if you have the time.
As you are probably starting to realize, that doesn't scale :)
>
> though i do strongly feel that the criticism of jakarta from the board
> has been unfair, i do think that there is a grain of truth in there.
> the official jakarta pmc is too small and has far too few active
> members for a project the size of jakarta. but jakarta's got too big
> and too diffuse for this to change easily or quickly.
Oh, not at all. I think that by adding more members to the PMC, we'll
solve the problem. The board, the directors of the corporation, have
assigned responsibility to the PMC. I can't see why that precludes
organizing the PMC as we see fit if it provides the oversight needed.
After all, isn't that the approach being taken in A-C?
>
>>> there are major issues about getting more folks on the jakarta pmc.
>>> at the moment, there are *major* procedure difficulties that are
>>> preventing our newly elected being officially recognized by the
>>> board as well as social ones. it is going to take time to reach our
>>> goal.
>>
>> What are the difficulties?
>
> some procedural, some social. jakarta doesn't even have a proper rule
> for deciding when an election succeeds. i've lost one election vote
> already for a senior apache member. then there's the effort of
> persuading people to accept the nomination.
>
> whatever the issues, the membership has stayed basically static whilst
> i've been a member even though numerous election votes have been
> passed.
Well, we can fix that. I think that more process isn't the answer -
just making it clear and streamlined.
>
> <snip>
>
>>> of course, some folks may see an ulterior motive. it will mean fewer
>>> product that i - and the rest of the jakarta pmc - are responsible
>>> for. (which may even free up some coding time :) but i really do
>>> think that there are products who need this move so that they can
>>> progress.
>>
>> I keep hearing that, but as a PMC member myself, I don't see where
>> it's inhibiting progress.
>
> there are lots of committers in jakarta-commons who have IMHO proved
> themselves worthy for election to the jakarta pmc. but it's going to
> be a very, very long time before this will happen.
>
> the flatter structure should mean that the goal of better supervision
> will be achieved for the products that move to apache commons quicker
> than we can achieve it for jakarta as a whole.
>
Don't you need the same amount of PMC members?
>> Why not just free j-c to be a TLP if it wants to?
>
> wouldn't bother me but IIRC we've been around this particular
> territory before and the general opinion was that there doesn't seem
> to be much point having a separate language-specific jakarta commons
> top level project when there's already an apache commons project.
This is getting to be like some kind of Monty Python gag. I can't
decide if it's the Spanish Inquisition or Life of Brian. <thinking/>
It's Life of Brian :
"What have the romans done for us???"
"well, there are actual mature codebases in j-c."
"And there's active new ones too! People joining all the time,
suggesting new stuff."
"Don't forget the strong community."
"Oh, and before the recognition and confidence by the rest of the Java
community was developed, no one talked to us."
"And our history! Don't forget our history..."
"Right! Aside from the active and mature codebases, the community, the
history, the links to other Jakarta sub-projects and the recognition
in the Java community, what have the Romans done for us?"
<sorry :D I couldn't resist...>
>
> there's also the issue of whether the jakarta-commons community wants
> to become top level. there are certainly some who do but i suspect
> that most want things to stay as they are. i might be able to persuade
> a few components to move (and so gaining some momentum for a move that
> way) but persuading the whole of jakarta-commons to move is certainly
> beyond me.
This is the bit that bugs me. Why should we be persuading anyone to do
anything? I'll support and help move people out if they want to move
out, I'll support A-C by trying to start/bring non-Java things there if
I can and help some other way if I have no code to offer. But I'm not
going to start trying to get people to move, especially with weird
marketing like "You'll still be part of Jakarta but you won't be!"
>
> i don't really see the problem with coorperating with greg and justin
> here.
<sigh>
What does cooperation mean? As an ASF member, I support having the A-C
project. As a developer that works in multiple languages and
environments, I'll bring code there and use what's there if needed. As
a Jakarta PMC member, I'll support any codebase/community that wants to
move out of Jakarta and fix what we can with our project. As a Jakarta
community member? I disagree that we need save the village by
destroying it. It's not just a yea/nay thing for me.
geir
> i have a feeling the pretty soon (given a sufficent influx of
> jakarta-commons components), the community atmosphere of
> jakarta-commons will infuse this place too - but with the added
> advantage that i get to bug greg and justin with the questions about
> licensing and so on that i get asked but can't answer ;)
>
>
> - robert
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, Rodney Waldhoff wrote:
> On Mon, 10 Nov 2003, robert burrell donkin wrote:
>
> > there are lots of committers in jakarta-commons who have IMHO proved
> > themselves worthy for election to the jakarta pmc. but it's going to be
> > a very, very long time before this will happen.
>
> Nominate them.
As I've been struggling through the current process, and still getting it
wrong by editing board-only files, I'll take the lead here and try to
organise another big-promotion effort rather than doing a handful at a
time.
More on J-PMC.
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Rodney Waldhoff <rw...@apache.org>.
On Mon, 10 Nov 2003, robert burrell donkin wrote:
> there are lots of committers in jakarta-commons who have IMHO proved
> themselves worthy for election to the jakarta pmc. but it's going to be
> a very, very long time before this will happen.
Nominate them.
>
> - robert
>
- Rod <http://radio.weblogs.com/0122027/>
iBatis
Posted by ZYD <el...@hotmail.com>.
Dear all,
I know this may be a little bit off the topic, but I really cannot get the answer elsewhere. sorry about this.
A lot guys here use iBatis, I want to use it too.
But I cannot find its API documentation.
Could anybody tell me where it is and give me an URL please?
Thanks.
bruce
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 10 Nov 2003, robert burrell donkin wrote:
>
> On 10 Nov 2003, at 22:33, Geir Magnusson Jr. wrote:
>
> >
> > On Monday, November 10, 2003, at 05:15 PM, robert burrell donkin wrote:
> >
> though i do strongly feel that the criticism of jakarta from the board
> has been unfair, i do think that there is a grain of truth in there.
> the official jakarta pmc is too small and has far too few active
> members for a project the size of jakarta. but jakarta's got too big
> and too diffuse for this to change easily or quickly.
But compared to a year ago it is changing. It was 7 people then or
something.
> >> there are major issues about getting more folks on the jakarta pmc.
> >> at the moment, there are *major* procedure difficulties that are
> >> preventing our newly elected being officially recognized by the board
> >> as well as social ones. it is going to take time to reach our goal.
> >
> > What are the difficulties?
>
> some procedural, some social. jakarta doesn't even have a proper rule
> for deciding when an election succeeds. i've lost one election vote
> already for a senior apache member. then there's the effort of
> persuading people to accept the nomination.
>
> whatever the issues, the membership has stayed basically static whilst
> i've been a member even though numerous election votes have been
> passed.
Really? I thought it had been slowly growing. The problem is that the
process for nominating, voting, notifying, accepting, notifying-sam,
sam-accepting-subscribe, notifying-board, waiting,
sam-adding-to-commiters.txt, someone-adding-to-who-we-are, done, is just
too damn long to do 1 at a time.
> there's also the issue of whether the jakarta-commons community wants
> to become top level. there are certainly some who do but i suspect that
> most want things to stay as they are. i might be able to persuade a few
Yeah, I've no great desire to push J-C out. Wtf would we call it for one
thing. "Yeah, we're Jakarta Commons, but we're not in Jakarta, no we're
not Commons, they're different, we're Jak...". Also, if a component leaves
J-C, how would it re-enter Jakarta.
> i don't really see the problem with coorperating with greg and justin
> here. i have a feeling the pretty soon (given a sufficent influx of
> jakarta-commons components), the community atmosphere of
> jakarta-commons will infuse this place too - but with the added
> advantage that i get to bug greg and justin with the questions about
> licensing and so on that i get asked but can't answer ;)
The alternative is to invite more ASF people onto the J-PMC as guests.
We import advisors, rather than hand-over our codebases [which is just a
psychological thing, but it does feel somewhat like that to me].
Hen
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by robert burrell donkin <rd...@apache.org>.
On 10 Nov 2003, at 22:33, Geir Magnusson Jr. wrote:
>
> On Monday, November 10, 2003, at 05:15 PM, robert burrell donkin wrote:
>
>> On 10 Nov 2003, at 21:05, Geir Magnusson Jr. wrote:
>>
>> <snip>
>>
>>> Now oversight is another issue entirely, but one that is fixable.
>>> If moving projects from j-c to a-c solves the oversight problem,
>>> then whatever magic happens when a j-c gets to a-c could easily be
>>> applied to jakarta's PMC, right?
>>
>> i'm not sure that it can.
>>
>> for a few months now, i've been subscribed to most of the jakarta
>> sub-project mailing lists. it started out with the mirroring but i
>> stayed as an experiment (partly as a result of the constant criticism
>> that the jakarta-pmc receives). last week my email client died. i've
>> spent all last week rebuilding a new IMAP server and transferring my
>> (very precious) email onto it. i still think that it's possible to
>> supervise something as big as jakarta - but only just. i don't spend
>> very much time coding now :(
>
> You aren't the only one that supposed to supervise.
we're all suppose to supervise everything - we're certainly responsible
for everything. subscription is an interesting experiment and is quite
informative.
though i do strongly feel that the criticism of jakarta from the board
has been unfair, i do think that there is a grain of truth in there.
the official jakarta pmc is too small and has far too few active
members for a project the size of jakarta. but jakarta's got too big
and too diffuse for this to change easily or quickly.
>> there are major issues about getting more folks on the jakarta pmc.
>> at the moment, there are *major* procedure difficulties that are
>> preventing our newly elected being officially recognized by the board
>> as well as social ones. it is going to take time to reach our goal.
>
> What are the difficulties?
some procedural, some social. jakarta doesn't even have a proper rule
for deciding when an election succeeds. i've lost one election vote
already for a senior apache member. then there's the effort of
persuading people to accept the nomination.
whatever the issues, the membership has stayed basically static whilst
i've been a member even though numerous election votes have been
passed.
<snip>
>> of course, some folks may see an ulterior motive. it will mean fewer
>> product that i - and the rest of the jakarta pmc - are responsible
>> for. (which may even free up some coding time :) but i really do
>> think that there are products who need this move so that they can
>> progress.
>
> I keep hearing that, but as a PMC member myself, I don't see where
> it's inhibiting progress.
there are lots of committers in jakarta-commons who have IMHO proved
themselves worthy for election to the jakarta pmc. but it's going to be
a very, very long time before this will happen.
the flatter structure should mean that the goal of better supervision
will be achieved for the products that move to apache commons quicker
than we can achieve it for jakarta as a whole.
> Why not just free j-c to be a TLP if it wants to?
wouldn't bother me but IIRC we've been around this particular territory
before and the general opinion was that there doesn't seem to be much
point having a separate language-specific jakarta commons top level
project when there's already an apache commons project.
there's also the issue of whether the jakarta-commons community wants
to become top level. there are certainly some who do but i suspect that
most want things to stay as they are. i might be able to persuade a few
components to move (and so gaining some momentum for a move that way)
but persuading the whole of jakarta-commons to move is certainly beyond
me.
i don't really see the problem with coorperating with greg and justin
here. i have a feeling the pretty soon (given a sufficent influx of
jakarta-commons components), the community atmosphere of
jakarta-commons will infuse this place too - but with the added
advantage that i get to bug greg and justin with the questions about
licensing and so on that i get asked but can't answer ;)
- robert
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 05:15 PM, robert burrell donkin wrote:
> On 10 Nov 2003, at 21:05, Geir Magnusson Jr. wrote:
>
> <snip>
>
>> Now oversight is another issue entirely, but one that is fixable. If
>> moving projects from j-c to a-c solves the oversight problem, then
>> whatever magic happens when a j-c gets to a-c could easily be applied
>> to jakarta's PMC, right?
>
> i'm not sure that it can.
>
> for a few months now, i've been subscribed to most of the jakarta
> sub-project mailing lists. it started out with the mirroring but i
> stayed as an experiment (partly as a result of the constant criticism
> that the jakarta-pmc receives). last week my email client died. i've
> spent all last week rebuilding a new IMAP server and transferring my
> (very precious) email onto it. i still think that it's possible to
> supervise something as big as jakarta - but only just. i don't spend
> very much time coding now :(
You aren't the only one that supposed to supervise.
>
> there are major issues about getting more folks on the jakarta pmc. at
> the moment, there are *major* procedure difficulties that are
> preventing our newly elected being officially recognized by the board
> as well as social ones. it is going to take time to reach our goal.
What are the difficulties?
>
> there are some very good folks in jakarta-oro, jakarta-regex and
> jakarta-commons who would (IMHO) find themselves pretty quickly
> elected to help supervise apache-commons if the product moved here. i
> think that the flatter structure will encourage this.
What 'product'? j-c? Why not just make j-c a TLP?
>
> of course, some folks may see an ulterior motive. it will mean fewer
> product that i - and the rest of the jakarta pmc - are responsible
> for. (which may even free up some coding time :) but i really do think
> that there are products who need this move so that they can progress.
I keep hearing that, but as a PMC member myself, I don't see where it's
inhibiting progress.
Why not just free j-c to be a TLP if it wants to?
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by robert burrell donkin <rd...@apache.org>.
On 10 Nov 2003, at 21:05, Geir Magnusson Jr. wrote:
<snip>
> Now oversight is another issue entirely, but one that is fixable. If
> moving projects from j-c to a-c solves the oversight problem, then
> whatever magic happens when a j-c gets to a-c could easily be applied
> to jakarta's PMC, right?
i'm not sure that it can.
for a few months now, i've been subscribed to most of the jakarta
sub-project mailing lists. it started out with the mirroring but i
stayed as an experiment (partly as a result of the constant criticism
that the jakarta-pmc receives). last week my email client died. i've
spent all last week rebuilding a new IMAP server and transferring my
(very precious) email onto it. i still think that it's possible to
supervise something as big as jakarta - but only just. i don't spend
very much time coding now :(
there are major issues about getting more folks on the jakarta pmc. at
the moment, there are *major* procedure difficulties that are
preventing our newly elected being officially recognized by the board
as well as social ones. it is going to take time to reach our goal.
there are some very good folks in jakarta-oro, jakarta-regex and
jakarta-commons who would (IMHO) find themselves pretty quickly elected
to help supervise apache-commons if the product moved here. i think
that the flatter structure will encourage this.
of course, some folks may see an ulterior motive. it will mean fewer
product that i - and the rest of the jakarta pmc - are responsible for.
(which may even free up some coding time :) but i really do think that
there are products who need this move so that they can progress.
- robert
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 02:43 PM, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 14:14:30 -0500 "Geir Magnusson Jr."
> <ge...@optonline.net> wrote:
>
>> I think that this slightly misrepresents the problem, as it's not
>> clear
>> what 'power' needs to be restored. I agree that there could and
>> should
>> be more representation on the PMC for legal reasons, but that can be
>> achieved with a bigger PMC.
>
> The power to dictate for themselves what the project should be doing
> and its direction.
They have complete power. They create new embryonic components in the
sandbox, the vote as a group to bring things into commons as
components, and the participants in each component dictate the
direction of their software. They decide when to release code and
inform the PMC. What are they missing?
> I believe the Jakarta PMC does not do a sufficient job of oversight
> (if any at all). Most of the PMC responsibilities has been devolved
> to the committers, but without the correct organizational structure in
> place as mandated by the ASF bylaws. Does the board (and, indirectly,
> membership) have any reports on what J-C is doing?
There are two things here. One is valid - the bit about oversight by
the PMC, as it's arguable that we could do a better job, although
recent events showed that the PMC is actively overseeing j-c - and the
second is not - the bit about the board getting reports on what J-C is
doing, as that is like requiring the board to get reports on the 'docs'
subproject of httpd. AFAIK, there is nothing that requires reports on
the pieces of a Apache Project. The Jakarta PMC report should be
sufficient.
>
>> This is far fetched - the Jakarta Commons has been *amazingly*
>> successful
>> in being a place for not-big-enough projects (we call them
>> components) to
>> be able to incubate and form. This aspect is what I fear will be
>> lost -
>> the huge collaborative effect that commons fosters. I don't always
>> agree with the side effects (I mean, does every damn bean need to log
>> via
>> commons-logging????), but the success can't be argued with.
>
> FWIW, I tend not to use the word components because it means something
> totally different to me in my ivory tower of academia. ;-)
And I would assume that changes week to week ;)
That's the word the community uses...
>
> I'm not debating the success of the J-C, but what I'm debating is that
> the Jakarta PMC has not been good about oversight or promoting
> projects to TLP status. And has been discussed, neither is Jakarta
> Commons sufficient for all languages. They would reject anything not
> written in Java (or they should be rejecting it as it directly
> violates their charter).
>
I guess I don't know what your definition of 'good about promoting
projects to TLP status'. Jakarta has spun off 'ant', 'avalon',
'james', 'maven', and the core of 'db'. Call it 5. That's more than
25% of the projects at Apache if you don't include 'Conferences' and
'Foundation' The only other Apache projects that promoted projects to
TLP status is httpd, with 1 (I'm assuming APR came from there - I don't
know the history) and XML with 1, Cocoon.
Now oversight is another issue entirely, but one that is fixable. If
moving projects from j-c to a-c solves the oversight problem, then
whatever magic happens when a j-c gets to a-c could easily be applied
to jakarta's PMC, right?
>> I'm not sure what you mean here. What do you define to be 'direct
>> user
>> interface'? In commons, there is a huge community, which was created
>> and
>
> Something a user interacts directly with. I think it's the easiest
> test for whether something belongs in 'Commons' or not. If you are
> writing an application the user executes directly, I don't think that
> belongs in Commons.
isn't that the majority of j-c 'projects'? (I won't use the word
'component'). Commons-logging? Jexl? If they don't belong in
commons, and don't belong in j-c due to questions of oversight, where
does it go? It's clearly not a TLP, is it?
>
>> fostered to scratch the itch of another community, Jakarta. And
>> within
>> commons, mini-communities were formed around each component. There's
>> an
>> interesting fractal-like structure to it, and one that joins unrelated
>> Jakarta subprojects in interesting ways. I think commons glued lots
>> of
>> jakarta sub-projects together. While I think that a-c could be a good
>> idea, I fear the difference may be that the communities you are
>> trying to
>> bring together don't have enough in common. People have been learning
>> this the hard way (for example, Yugoslavia...).
>
> I think you're misunderstanding our goals here. We're not trying to
> force anyone to come together. We're offering an alternative
> organizational structure to J-C that may be more conducive to certain
> communities. If a component is happy in J-C land, it can stay there.
> But, if they want to truly be able to manage the project themselves
> (as I believe each project should), then I think A-C is a compelling
> alternative. -- justin
Well, I'm just trying to sort through the fog. I think it behooves us
to fix Jakarta problems, because it's been quite successful in both
creating good software and good communities. I keep hearing "Jakarta
must die" from people, and can't figure out why...
geir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, November 10, 2003 14:14:30 -0500 "Geir Magnusson Jr."
<ge...@optonline.net> wrote:
> I think that this slightly misrepresents the problem, as it's not clear
> what 'power' needs to be restored. I agree that there could and should
> be more representation on the PMC for legal reasons, but that can be
> achieved with a bigger PMC.
The power to dictate for themselves what the project should be doing and
its direction. I believe the Jakarta PMC does not do a sufficient job of
oversight (if any at all). Most of the PMC responsibilities has been
devolved to the committers, but without the correct organizational
structure in place as mandated by the ASF bylaws. Does the board (and,
indirectly, membership) have any reports on what J-C is doing?
> This is far fetched - the Jakarta Commons has been *amazingly* successful
> in being a place for not-big-enough projects (we call them components) to
> be able to incubate and form. This aspect is what I fear will be lost -
> the huge collaborative effect that commons fosters. I don't always
> agree with the side effects (I mean, does every damn bean need to log via
> commons-logging????), but the success can't be argued with.
FWIW, I tend not to use the word components because it means something
totally different to me in my ivory tower of academia. ;-)
I'm not debating the success of the J-C, but what I'm debating is that the
Jakarta PMC has not been good about oversight or promoting projects to TLP
status. And has been discussed, neither is Jakarta Commons sufficient for
all languages. They would reject anything not written in Java (or they
should be rejecting it as it directly violates their charter).
> I'm not sure what you mean here. What do you define to be 'direct user
> interface'? In commons, there is a huge community, which was created and
Something a user interacts directly with. I think it's the easiest test
for whether something belongs in 'Commons' or not. If you are writing an
application the user executes directly, I don't think that belongs in
Commons.
> fostered to scratch the itch of another community, Jakarta. And within
> commons, mini-communities were formed around each component. There's an
> interesting fractal-like structure to it, and one that joins unrelated
> Jakarta subprojects in interesting ways. I think commons glued lots of
> jakarta sub-projects together. While I think that a-c could be a good
> idea, I fear the difference may be that the communities you are trying to
> bring together don't have enough in common. People have been learning
> this the hard way (for example, Yugoslavia...).
I think you're misunderstanding our goals here. We're not trying to force
anyone to come together. We're offering an alternative organizational
structure to J-C that may be more conducive to certain communities. If a
component is happy in J-C land, it can stay there. But, if they want to
truly be able to manage the project themselves (as I believe each project
should), then I think A-C is a compelling alternative. -- justin
Re: Benefits of Apache Commons was Re: [REQUEST] Product groupings
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On Monday, November 10, 2003, at 01:18 PM, Justin Erenkrantz wrote:
> --On Monday, November 10, 2003 6:04 AM -0500 "Geir Magnusson Jr."
> <ge...@optonline.net> wrote:
>
>> Is there a good post describing the benefit of these changes? I don't
>> understand the upside of moving oro and regex from one umbrella to
>> another
>> umbrella, nor trying to get j-c projects to move to a-c. I see j-c
>> as a
>> vibrant and prolific community, and wonder about the effects of
>> breaking it
>> apart.
>>
>> I either missed the point somewhere (likely) or don't get it (also
>> likely).
>
> Okay, we've gone over these before, but I'll try to restate what I
> believe the benefits to be for the newcomers. Others are welcome to
> chime in and comment.
>
> - I don't quite believe it'll be the same sort of umbrella as J-C or
> Jakarta itself. We're trying to advocate that groupings should
> receive their own topic-centric mailing list. We're trying to
> advocate a higher degree of interaction with the PMC, etc. From all
> reports, J-C is starting to collapse under its own weight. Something
> has to give.
>
> - It's isn't quite a lateral move as you'd make it out to be. I
> believe it, at best, would be cutting out one level of bureaucracy
> (namely the Jakarta PMC) and restoring power to committers working on
> code. This has the advantage of allowing the actual developers
> working on the projects to have a voice in the PMC (and, legally, this
> is as they are required). I've heard concerns from J-C folks that
> they don't really have any direction from the Jakarta PMC on what to
> do, nor do they have any say. Yet, in A-C, there would be *at least*
> one Commons PMC member per project who is active - the Commons PMC
> needs to ensure that as part of its oversight responsibility.
I think that this slightly misrepresents the problem, as it's not clear
what 'power' needs to be restored. I agree that there could and should
be more representation on the PMC for legal reasons, but that can be
achieved with a bigger PMC.
> - A chance to re-organize projects that aren't 'quite big enough' for
> TLP status that are meant for reusability under one shared PMC. I
> believe that a lot of 'small' projects will share common needs and
> requirements: a PMC that understands that can be extremely beneficial
> with the right processes and tools in place.
This is far fetched - the Jakarta Commons has been *amazingly*
successful in being a place for not-big-enough projects (we call them
components) to be able to incubate and form. This aspect is what I
fear will be lost - the huge collaborative effect that commons fosters.
I don't always agree with the side effects (I mean, does every damn
bean need to log via commons-logging????), but the success can't be
argued with.
>
> - It's harder to build communities around reusable libraries that
> don't have any direct user interfaces: it takes a lot of time and
> effort and doesn't usually start with the community size that mandates
> TLP status. And, I'll point out that this isn't quite the same as the
> incubator - which is only meant as a legal checklist.
I'm not sure what you mean here. What do you define to be 'direct user
interface'? In commons, there is a huge community, which was created
and fostered to scratch the itch of another community, Jakarta. And
within commons, mini-communities were formed around each component.
There's an interesting fractal-like structure to it, and one that joins
unrelated Jakarta subprojects in interesting ways. I think commons
glued lots of jakarta sub-projects together. While I think that a-c
could be a good idea, I fear the difference may be that the communities
you are trying to bring together don't have enough in common. People
have been learning this the hard way (for example, Yugoslavia...).
>
> - A learning place where these reusability projects (or groupings of
> projects) that do become 'big enough' to become TLPs. As these
> collections of functional groupings are defined and projects start to
> develop communities that can manage themselves, I believe the Commons
> PMC should advocate that they should be promoted en masse as a new
> TLP. This respects the current feelings (among some) that the ASF
> should reorganize around very specific TLPs rather than broad PMCs.
I see both sides of that argument, and feel that whatever problems one
has or had with jakarta, you can't argue with the amazing success in
terms of software and communities. I do think that Jakarta grew too
large, or too diverse, actually, for it's own good - the cohesion
seemed to diminish a bit.
>
> - Yet, we will have to find the balance on what should be spun off and
> what shouldn't be. IMHO, the ideal code in Commons is one that is
> 'done' and doesn't need much work or oversight. Hence, creating a TLP
> doesn't make sense for certain classes of libraries as when they're
> done, they're 'done.' You've created the 'perfect' math library. > Yay.
Hm
>
> - From my C-centric perspective, a place where I can develop reusable
> code and libraries as there are no PMCs willing to accept reusable C
> libraries anywhere in the ASF such as serf. (APR did for a little
> while, but that was under extreme protest.) So, I'm merely here to
> scratch my own itch as I'd expect most people should be, too.
Why not bring them to Jakarta commons ? That probably wouldn't stretch
the boundaries of the charter any further than it has been already ;)
>
> Hope this begins to answer your question. -- justin
>
Thanks for the info.
geir
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geirm@optonline.net