Quoting Harish Krishnaswamy <[EMAIL PROTECTED]>: > Thanks Craig, this is elaborate, informative and puts the issue in my > perspective. May be this > should be put on the website too somewhere. > > Here are my inferences so far... > > <inferences> > ASF is a group of projects administered by the Apache board members. The > board delegates certain > responsibilities over to the PMCs of the individual projects while still > maintaining the authority > and management responsibilities. The PMC is responsible for a wholesome code > and community of the > project it oversees but does not have the authority to recognize new > projects. > > Jakarta started out as a single project for a web container and has grown > into a foundation of > projects in itself without sufficient administration/organization. > </inferences> >
Waiting for the bureacracy to be created first is kind of antithetical to the way most open source developers think :-). > Here are my thoughts distilled from a lot others'... > > * I think the projects at ASF should be classified in some way (preferably by > technology like we > have now for xml, db etc.) into umbrella projects. All projects piled > together at the top level > would not convey very well. This is where Jakarta would need redefinition. > Seems like the inital > motivation, server side web development, is a good fit. And that would mean > some reshuffling. The problem with "graph shaped" (single inheritance) hierarchies is that sometimes a single project fits more than one place. For example, where do you put Cocoon? It's clearly a thing that fits into an "XML Technologies" sort of place. It's also a thing that clearly fits into a "server site technologies" sort of place. The answer that Cocoon chose (the right one, IMHO) was to be a separate TLP that is *linked* to both of those technology's web sites. But, the more fundamental principle is that the legal organization of the ASF need not have anything at all to do with how websites are organized and how projects are made visible. > * I think each umbrella project or each project within could have a PMC and > each project should > maintain a PMC membership of atleast 51% of its committers to sustain. That's pretty much the way that Jakarta works now (we've focused on expanding the PMC membership over the last year to ensure coverage from all the subprojects). But, as a Jakarta PMC member, it's still a daunting thought to be held responsible for oversight of all the code, and all the releases, across all of Jakarta. It's hard enough for me, for example, just to stay current on the three projects I watch and try to participate in (Commons, Struts, Tomcat). I'm pretty clueless about what the Tapestry folks are doing, yet *I* need to approve releases? Having Tapestry committers on the PMC helps, but isn't sufficient. > * I think the website should match the organizational structure to avoid > confusion. I don't agree. The website(s) should be focused around making it easy for users to find out what Apache projects might have products that are relevant to their needs. The internal project organization is an implementation detail. > * I think the board should classify the newly adopted projects. Projects that > churn out of existing > projects should be brought back to the board for classification at the time > of creating new CVS > repositories. > * Each umbrella could have a commons and a sandbox to share and play. > * There could be a top level commons to house cross-umbrella components. > > It seems like what we now have is pretty much in good shape and only means > that the following > actions take place... > > * Reorganize Jakarta (and may be others??) The interesting question is what Jakarta becomes after the subprojects that want to become TLPs do so. I suspect that keeping it as a brand is likely to be helpful, but the brand has been pretty muddled too (is it "Apache Struts" or "Jakarta Struts"? Depends on which book title you read :-), and the earlier perceptions that Jakarta had for high quality server side Java code is starting to slip. > * Enforce project level PMC membership > IMHO, it's just not good enough to satisfy the oversight requirements delegated to the PMCs by the ASF Board. > Just my thoughts. > > Regards, > Harish > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
