nicolaken 2004/01/20 00:37:34
Modified: site/projects juddi.cwiki wsrp4j.cwiki xmlbeans.cwiki
Log:
Add the status reports
Revision Changes Path
1.17 +75 -0 incubator/site/projects/juddi.cwiki
Index: juddi.cwiki
===================================================================
RCS file: /home/cvs/incubator/site/projects/juddi.cwiki,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- juddi.cwiki 18 Jan 2004 06:35:54 -0000 1.16
+++ juddi.cwiki 20 Jan 2004 08:37:34 -0000 1.17
@@ -183,6 +183,81 @@
__DONE__
+!!!Incubation Status Reports
+
+!!2004-10-19
+{{{
+jUDDI Status Report
+
+ * is the STATUS file up to date? (also post link)
+
+ jUDDI's status file (cwiki) is up-to-date though
+ the site still needed to be rebuilt for the latest
+ changes to be seen.
+ http://incubator.apache.org/projects/juddi.html
+
+ * any legal, cross-project or personal issues
+ that still need to be addressed?
+
+ No outstanding issues.
+
+ * what has been done for incubation since the
+ last report?
+
+ All four project committers have submitted
+ CLA's. We're still waiting on confirmation
+ for one of these.
+
+ A jUDDI Web Site has been created at Apache
+ and the original jUDDI web site redirects
+ visitors to the new web site.
+ http://ws.apache.org/juddi/
+
+ An cvs module is in place and the jUDDI source
+ has been imported. Java packages have been renamed
+ from "org.juddi" to "org.apache.juddi" and all
+ source files have been modified to include the
+ ASF copyright notice.
+
+ The mailing lists [email protected] and
+ [email protected] have been created and
+ are being archived.
+
+ Issue tracking has been setup under Jira.
+
+ Gump is successfully building jUDDI.
+ http://lsd.student.utwente.nl/gump/ws-juddi/
+
+ * plans and expectations for the next period?
+
+ Still need to acquire and check in license files
+ for dependent non-Apache libraries that are
+ distributed with jUDDI.
+
+ Waiting to be notified that the fourth committer's
+ CLA has been received and his account created and
+ granted the appropriate privs.
+
+ Assemble a to-do list (roadmap) for future
+ development and plan the next jUDDI release.
+
+ We'd like to wrap up the few issues that are
+ outstanding and exit incubation before the next
+ period comes to a close.
+
+ * any recommendations for how incubation could run
+ more smoothly for you?
+
+ I've heard reference to a STATUS file as well as
+ the jUDDI cwiki that I've been updating. While I've
+ assumed they are one-in-the-same I'm not certain
+ of that (perhaps you can enlighten me). If they are
+ not they same thing then I'm confused about the need
+ to keep status in two different places. Even this
+ status report is more or less a reformatted version
+ the cwiki document.
+}}}
+
!!!Organizational acceptance of responsibility for the project
If graduating to an existing PMC, has the PMC voted to accept it?
1.8 +47 -1 incubator/site/projects/wsrp4j.cwiki
Index: wsrp4j.cwiki
===================================================================
RCS file: /home/cvs/incubator/site/projects/wsrp4j.cwiki,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- wsrp4j.cwiki 7 Jan 2004 21:01:06 -0000 1.7
+++ wsrp4j.cwiki 20 Jan 2004 08:37:34 -0000 1.8
@@ -38,7 +38,53 @@
!!! Incubation status reports
-* none yet
+!!2004-10-19
+{{{
+Status report for the Incubator
+
+* is the STATUS file up to date? (also post link)
+
+ The cwiki file on the incubator site is more or less up to date.
+ http://incubator.apache.org/projects/wsrp4j.html
+
+* any legal, cross-project or personal issues
+ that still need to be addressed?
+
+ There is a effort under way to create a portals super project
+ that would have the WSRP4J project as a sub project. This is a
+ desireable thing for the WSRP4J project since it would give us
+ focus as a portal-related technology.
+
+* what has been done for incubation since the last report?
+
+ This is the first report. However, since we started we have:
+ 1. Imported all the code into CVS.
+ 2. Granted committer rights to initial committers.
+ 3. Established mailing lists.
+ 4. Created Bugzilla components, although no bugs have been
+ reported yet using Bugzilla.
+ 5. Created a website using Forrest.
+ 6. Create a TODO wiki to encourage collaboration on features
+ and enhancements.
+ 7. Joined the Gump nightly build process.
+ 8. Voted to join portals.apache.org
+ 9. Voted to substitute JIRA for Bugzilla
+
+* plans and expectations for the next period?
+
+ 1. Continue development work on outstanding WSRP 1.0 items
+ (see TODO wiki:
http://nagoya.apache.org/wiki/apachewiki.cgi?WsrpToDoList)
+ 2. Continue to build the community by encouraging developers
+ to contribute code. We are building a user population, but few
+ outside developers have made code contributions.
+
+* any recommendations for how incubation could run more smoothly for you?
+
+ I'm confused on the difference between a STATUS file and the cwiki
+ page on the Incubator website. Do I need both?
+
+* etc (your own thoughts on what is important would be helpful!)
+}}}
!!! Incubation work items
1.8 +160 -0 incubator/site/projects/xmlbeans.cwiki
Index: xmlbeans.cwiki
===================================================================
RCS file: /home/cvs/incubator/site/projects/xmlbeans.cwiki,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- xmlbeans.cwiki 14 Jan 2004 06:20:05 -0000 1.7
+++ xmlbeans.cwiki 20 Jan 2004 08:37:34 -0000 1.8
@@ -137,6 +137,166 @@
-- Are the decision-making guidelines published and agreed to by
all of the committers?
+!!!Incubation Status Reports
+
+!!2004-10-17
+{{{
+
+- Status report for the Incubator -
+
+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.
+
+}}}
+
!!Organizational acceptance of responsibility for the project:
-- If graduating to an existing PMC, has the PMC voted to accept it?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
