In summary the most serious issues to this proposal are: 1. diversity of committership. I'd personally like to see >51% of the ACTIVE committership from a different company. So long as a decision in one company can MAKE the vote, you don't have an Apache project, you have a corporate subproject at Apache.
2. Pick your project. I think it would have been a lot less confusing to mail the proposal to Jakarta or XML. Personally, if this is a Java only project, I think it should go to Jakarta. If it is a mult-platform C a/o C++ and Java, then it make sense for it to be part of XML. The proposers and sponsors should just decide and go in a single direction rather than kicking off a big debate. 3. Duplication of effort. The project encompasses schema validation which is done my XML parsers and it is Yet Another XML->Java binding API (there are some here and several elsewhere). From the standpoint of something I'd commit code to, this bores the crap out of me. From the standpoint of acceptability, its totally irrelevant. Choice is good, competition and cooperation exist not only in opensource but often in the same area of given projects. Thus if it can become an Apache community, then its irrelevant. 4. Machiavelli - I originally posted this to a private list because I didnšt think it was good to say publicly, but rounding things out here might be good. Thus anointing BEA into the real open source and Apache world is a motivation. I don't think this project should be accepted without meeting the basic qualifications because of that, but maybe its a motivation to be a little more helpful than usual ;-). It might also round out the power structure at Apache a little if BEA began participating. Suggested courses of action: 1. Immediately begin recruiting other interested folks to round out the committership. This should not exit the incubator until >51% of regular voting committers are not from the same company. (meaning no "show committers" who never vote ;-) but round out the percentage) 2. Pick a project (XML or Jakarta) and say "would you accept this given it is acceptable out of the incubator" 3. Steven should begin suffering the incubator and moving the bureaucratic wheels. 4. set up the mail lists 5. Work on Gump integration and source structure to match other projects. 6. Project should be a subcontext of incubator for the moment. There are far more issues that must be worked out and confusion between a potential Apache project and an Apache project should be avoided. I still feel a little bit like this should start on sourceforge, round out the community issues, then move to incubator.... Thoughts? -Andy -- Andrew C. Oliver http://www.superlinksoftware.com/poi.jsp Custom enhancements and Commercial Implementation for Jakarta POI http://jakarta.apache.org/poi For Java and Excel, Got POI? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
