You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by David Remy <dr...@bea.com> on 2004/01/17 23:48:44 UTC

XMLBeans status report, Jan 2004

- 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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: XMLBeans status report, Jan 2004

Posted by Ted Leung <tw...@sauria.com>.
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/


Re: XMLBeans status report, Jan 2004

Posted by Ted Leung <tw...@sauria.com>.
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/


Re: XMLBeans status report, Jan 2004

Posted by Ted Leung <tw...@sauria.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org