[prev in list] [next in list] [prev in thread] [next in thread]
List: xmlbeans-dev
Subject: Re: XMLBeans status report, Jan 2004
From: Ted Leung <twleung () sauria ! com>
Date: 2004-01-18 19:56:18
Message-ID: 61C4DFF4-49F0-11D8-B11A-000A959A114E () sauria ! com
[Download RAW message or body]
This looks accurate to me.
I did update the status file in the incubator cvs @
cvs:incubator/site/projects/xmlbeans.cwiki, but I'm not sure how to get
the site to rebuild.
As mentioned below, the big challenge is to grow the community.
Ted
On Jan 17, 2004, at 2:48 PM, David Remy wrote:
> - 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)
>
The deterimining factor is the licensing. If the license is ASF
compatible then there shouldn't be a problem hosting it. How to manage
the version dependencies is up to us.
> 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: xmlbeans-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
> Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic