My rough idea of a project plan for the FM branch would be:
- write test cases for everything up to "SimpleFeature"
- port shapefile and postgis over to use SimpleFeature
- slam the change onto trunk, and explore the rest of the API as
aspects of the orphaned complex-feature branch trickle in out of their
long cold night
I would recommend having support for postgis, shapefile, oracle, ArcSDE,
and DB2 datastores as these seem to be the ones that people actually
care about. Are there any non-trivial datastores that actually produce
"complex features"?
I'm just concerned that if FM merges-in as a half-a-product, you're not
going to find too many people who will actually go about
using/testing/fixing it as there's a no reason to actually "upgrade"
from 2.2.x to FM.
If you step back and imagine yourself as someone looking at geotools
from the outside, I'm sure they would consider the "FM *fully* merged"
in when:
0) finish the FM branch
a) its actually merged in on trunk
b) geotools declares it "stable"
c) there's at least 1 datastore that reads&writes complex features (+
all the old ones doing simple features)
d) both udig and geoserver have transitioned to it (+ whomever else)
e) both udig and geoserver split out releases based on it
f) bugs reported get fixed
g) continue (e) and (f) until the rate of report is "about what it is now"
The minium for letting people continue with the tasks you listed that
require FM is probably (b), but (a) shouldnt really occur until the FM
branch is pretty much "good and stable". I would expect (b) to come
quickly after (a) - but our experience with 2.2.x may contradict that.
I think to do any planning, we need to know what needs to be done on the
FM branch to get "done" (ie. "0" above), hopefully with some time
estimates. Then we need to know who's able to do what, and what kind of
time availability they have.
The last update on FM was almost a month ago:
>>I have the core modules (api,main,refrencing,...) compiling against
the new feature model. Some of the tests in main still fail...
Anyone have the current status? Warm fuzzies would be good.
So:
a) need to define scope for what 'state' the FM needs to be in before it
gets merged onto trunk.
+ I argued, above, for a fairly complete version of it, but
arguments can certainly be made for 'less'.
b) we need some type of todo list for getting the current FM from what
it is now to whats required in (a)
+ dont forget a testing and bug-fixing plan
c) we need to define our resource and get them "up to speed."
You mentioned that the FM-required projects will be starting mid-june to
early july. I must admit that I'm a bit skeptical of geotools actually
being able to move that quickly - someone's going to have to throw some
$$ or resources at it.
Anyways, could we start by getting a list of FM 'stakeholders'? Here's
my guess (hopefully I havent missed anyone):
* Justin (TOPP)
* Chris (TOPP)
* Jody (RR)
* RobA (SCO)
* Gabriel (AXIOS)
* Bryce (?)
* GridCoverage folks (Alessio volunteered)
It would be great if they could reply and say what there interest is in
FM (even if just "I think it will be good in the future"), what type of
timeline constraints they have (if any), and what kind of resources they
have that they could throw at it (if any).
dave
ps. At least two people mentioned that GC 'requires' or affects FM,
which (if true) would mean that there needs to be some planning between
FM and GC. This could really throw a "wrench in the works" if FM need
modification to properly accommodate GCs (or visa-versa).
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
