David Blasby wrote:
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"?
Maybe just shapefile then, we need help to get this stuff done. Note
ArcSDE is out of the build and will not get back in until some time is
spent producing a mock jar.
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.
I can find lots of reasons, most of it around less code and more
consistent code. DataUtilities has grown large and fat as more and more
hacks were
added to make geotools useful.
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"
True and True, I would add documentation to the list.
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.
It all depends on how much help people are willing to put into the FM
branch, the chat is going right now and we have three volunteers, so
there is hope for the community yet. :-)
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.
Indeed that is what I want to see for next meeting, for both FM and CM
branches. I will not be able to do a time estimate until I finish these
IRC session - need a bit of a measure to start off with.
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.
It has been stuck for lack of a process to produce JARs from geoapi,
justin was cranking them out by hand because he was working on his own.
Today we will get our first jar out, and set up the FM branch for
"group" development again.
So no warm fuzzies, other then the fact we are on it. If you check the
GeoAPI branch you will see that some progress has been made especially
on the documentation front.
Jody
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'.
Yeah, I think we gotta go for less, setting the bar too high will take
longer, and time is the danger here.
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
Plan first, TODO second, goal for next GT meeting.
c) we need to define our resource and get them "up to speed."
That part is in progress, in terms of getting up to speed, I am not sure
any resources will be commited until the scope of work is established.
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.
Agreed, and TOPP has been doing so for months, time to ask around for
help, lets get a plan and scope (as it is much easier to commit to a set
target).
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).
- it is the future, Mid June, not sure what resources I have (beyond
blood sweat and tears)
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).
Well Bryce has kept up communication on that front, as long as we stay
away from the "opperation" API until the grid coverage people review it
I am happy. Also the focus here should be on getting the FM branch
merged in, the existing codebase will not use all of it yet anyways.
Jody
-------------------------------------------------------
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
