On Mon, 10 Nov 2003, 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. 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
