David Blasby wrote:
(resending because my email was having problems)
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 disagree here. Especially since only two of these modules have active
module maintainers.
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"
Unfortunatley fm is not a "one shot deal". If people just wait on the
outside forever it will never happen.
Also the whole merging to trunk is going to be an issue now that fm has
been out so long. There are lots of bug fixes getting onto trunk that fm
is going to miss. However we could just kill most of fm and port modules
directly from trunk as they get ported over.
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.
I agree here, a more formal plan is definitlry needed. I would also like
to see this come with a change in project policy. I know chris (or
someone) has brought up in the past a more linux like development model
in which odd numbered releases are "unstable". This would be nice as
instead of making people work on branches and essentially forking the
project we could explicity plan for them to do there r&d in contolled
time slots. However IMHO FM is a special case as it really requires a
new major version number.
The view of stability in our project also comes in multiple forms. There
is stability in terms of a stable code base, however what about in terms
of stable development practices. I talked to two people at GeoNetwork
last week who said they evaluated geotools and a platform but decided
agianst it because they literally couldn't figure out what was going on
with regard to code being where and everything being branches. And as
one of our major problems is manpower, this is not good.
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."
I think its going to be more accurate to say that other projects (udig /
geoserver) will just have to switch to fm. We wont be able to bring fm
back to trunk with a simple "svn merge". Its been out for too long and
there is too much parallel development going on alonside trunk.
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).
My biggest stake is getting everyone back in the same pool. Having a
better feature model to accomdate simple and advanced uses will be a
huge step forward in doing that as people will be able to do more
straight with trunk. And if we want to avoid another fork in the code
base as GML 3 comes down the pipe this needs to happen.
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
--
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------
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
