On Monday, November 10, 2003, at 02:43 PM, Justin Erenkrantz wrote:
--On Monday, November 10, 2003 14:14:30 -0500 "Geir Magnusson Jr." <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Geir Magnusson Jr 203-247-1713(m) [EMAIL PROTECTED]
