- Status report for the Incubator - (sorry for the delay, also thanks to xmlbeans-dev list for their quick response - well, delayed quick response ...)
Overall the xmlbeans project is progressing with good committer productivity and a growing user community. Converting over the Apache CVS systems and build process has been accomplished along with various other Apache administrative tasks such as setting up the Apache website. There is some movement towards growth in the development side of the community with one contributor (Dutta Satadip) submitting a nice enhancement and several other contributors submitting small patches related to bugs. More on each of the bullet points below. * is the STATUS file up to date? (also post link) <Cliff Schmidt> We need to update the status file with the latest incubator guidelines. We're mostly there, but there are a couple things that need to be added. I also think the status file needs to be updated in one or two other ways. For instance, the tasks completed should now include: - build xmlbeans website - grant some committers access to xml-site (Cliff and Remy) </Cliff Schmidt> http://incubator.apache.org/projects/xmlbeans.html * any legal, cross-project or personal issues that still need to be addressed? In general it appears xmlbeans is through most of the known issues that existed getting started. The committers have been able to be productive and there is a lot of code being created in version 2 and fixes are being made into version 1. One issue that we have run into is how best to accommodate commonly used api jars primarily (but not exclusively) JCP related api's from SUN. We are not sure the appropriate process to determine whether we can use a particular jar and host the jar in the xmlbeans build. examples of api's that we are unsure the appropriate/best way to deal with are: * JSR173 api and JSR 173 RI (Streaming API for XML, a.k.a., STAX) - the JSR173 RI dependency is temporary. Currently xmlbeans downloads it from external server during the build process * SAAJ api - we used the saaj-api source code in axis. * xml commons resolver (Apache jakarta) * jaxen (jaxen.sourceforge.net - apache-style license, but not apache) Here are some specific questions on this subject that David Bau posted: <David Bau> - We currently load resolver.jar and jaxen.jar if the user happens to put them on the classpath, and throw a runtime exception if the user tries to use a resolver- or jaxen- dependent feature without those JARs present. This is OK, but it would be nicer for users if resolver and jaxen were just included in xbean.jar, but this presents both licensing issues (for jaxen) and possible-version-conflict issues (for commons resolver). A question is: is there a nice way we include resolver.jar and jaxen.jar inside xbean.jar, or should we stay away from that idea? - We need the JSR 173 API to run, and this is definitely something that we want to be able to distribute either directly inside xbean.jar, or at least directly inside Apache since it's so core. In other words, we can't expect users to do anything without this API present. I've noticed that for other APIs, such as SAAJ, Apache seems to have a "clean room" copy of the APIs. Should we be making such a copy of the JSR 173 APIs? What is the right way to do this? </David Bau> * what has been done for incubation since the last report? <David Bau> The main thing is that we've been working on the project. We're getting more folks hanging around on the lists; we're getting some of the code that we've talked about on the lists and on the wiki actually written and checked in. We've been encouraging the wider community to critique and contribute ideas and code. Community-building is a gradual process; we don't have a mature community yet, but we've certainly gotten started at building a little one. </David Bau> * source code checkin (was that since last status report?) * build and test ant scripts established * website updated including docs, source code access, etc. * established version 2 effort and modified CVS tree accordingly * proposed (close to implementing I think) branching strategy for version 1 (by Kevin Krouse) * gump integration (thanks to Robert Burrell Donkin) * plans and expectations for the next period? * development on v2 will continue incorporating community feedback. * continued work on soliciting volunteers for contribution and committership. * work on organizing bug tracking and follow up * xmlbeans-1.01 distribution (minor bug fixes to v1) * improve process of bug testing and fixing from BugZilla contributions. * any recommendations for how incubation could run more smoothly for you? Incubation seems to be going well with one, albeit an important one, challenge of getting outside committers. Having a large existing codebase in a fairly complicated area makes it challenging. The growing user community and the excellent posts that we are getting on the xmbleans-dev list make us optimistic we will make some breakthroughs in the next period. * things that xmlbeans could/will improve on (summary, contributed by Cliff Schmidt) 1. Bug management: http://nagoya.apache.org/bugzilla/buglist.cgi?product=XMLBeans (as has already been mentioned by one or two others) -- This is just as much related to community as code. Of the 12 bugs entered so far, we haven't done a very good job of keeping them updated with status. We should encourage people to file bugs by showing that the committers are actually responding to them (even if the response is "need more info to repro" or simply noting the priority). 2. Web site: http://xml.apache.org/xmlbeans/ -- We got this built and running but we need to keep it updated. For instance, it still shows the ApacheCon advertisement. 3. Binary download. -- We started to get this done, but I don't think we ever finished. Actually, I'd like to try to get this done in the next couple days. 4. PPMC -- The incubator introduced the idea of a PPMC and we haven't responded to this yet. I'll follow up in a separate post on what needs to be done. 5. Status file -- We need to update the status file with the latest incubator guidelines. We're mostly there, but there are a couple things that need to be added. I also think the status file needs to be updated in one or two other ways. For instance, the tasks completed should now include: - build xmlbeans website - grant some committers access to xml-site (although I forgot who has this; I think it is me and Remy) 6. Committer keys Bau and I were both able to make it to ApacheCon and we both participated in the key-signing party. We need to get other committers to make keys and get them signed by me and Bau whenever we run into each other in person again. 7. New Committers The biggest issue of all is definitely the new committers, as everyone seems to agree. We really need to find more ways to encourage others to contribute. I think we are all ready and willing to share some of the responsibility; we just need to find people who are showing enough interest (and action) to be considered for committership. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
