Hi guys,
I know communication about fm has been slim. But please keep in mind the only reason we can even consider moving on fm is because certain people have spent *volunteer* time to get it into such a shape, which in my view is a failure in the management process of the project. And please dont take this as pointing a finger, because i am to blame as much as anyone else. But in defense there has been lots of discussion about certain issues with fm the geotools and geoapi lists and the only people that have cared are Jody and Bryce. So I turn it around on other people to say they haven't been exactly interested in it which doesn't exactly facilitate communication. People have just been expecting it to work. And unless I am mistaken this community decided to go forward with this long before I even became an active member. Perhaps things have changed and this needs to be revisited and in PR's words perform a formal cost benefit analysys. But that is something for the PMC to decide on.
That being said, here are where things are at:
We have api, main, referencing, coverage building (however not passing all test cases). All the xml, data (as in DataStore), and jdbc stuff has been ripped out of main.
Now I think the timings "6 months" vs "1 month" need a bit of clarification. My original estimate of 6 months was to get geotools based on FM to the state where geotools is right now. IE relatively stable and well tested (with *all* data stores working).
And IMHO, 6 months is very optimistic unless we can actually get more people vested in seeing this thing go. With everyone worried about getting other applications going which just use geotools and willing to hack around certain problems.
So here is what I see possible in one month (and again with more manpower):
1. Feature model turning over (ie. all major bugs fixed and we are actually able to create usable features).
2. Filter / expression subsystem ported (most of this is already done)
3. Data module ported.
4. 1 or 2 data stores ported over (postgis and shapefile for instance).
Again I say this is optimistic because as of right now only 1/2 of a single developers time is devoted toward this. However I know that Gabriel and Jody are also willing to kick in some time toward this which makes me optimistic.
I apologize if I seem pessimistic about this but I really think people need to know where things are at with fm. It is a rewrite of the core of geotools so I don't see how much else can be expected. IMHO fm cant be involved in another 2.x release, it needs to be called Geotools 3, if for any reason to drive home the fact that it is drastically different, to users and to developers.
Ok, sorry for that, only good vibes. The list above I believe is enough for OWS-4, and most importantly, enough to do it right. FM is a huge step forward in terms of fixing some of the major problems with geotools. And with OWS-4 driving things, what we get it is going to be well tested with most of the major kinks done right.
-Justin
David Blasby wrote:
During the Grid Coverage/Renderer improvements IRC today, we talked about merging the grid coverage branch onto trunk.
See:
http://docs.codehaus.org/display/GEOTOOLS/2006/05/01/Renderer+IRC
and the " Renderer improvements meeting part 2 (Grid Coverge Merge to Trunk)" message thread.
I know almost nothing about the FM branch, and the last I heard was that it was going to be another 6 months before its done. Apparently, thats incorrect, and its going to be finished up next month (june) because there's a lot of OWS-4 work thats depending on it.
Perhaps we can get a check-in from the folks who are working on FM, or who are current stalled (or will soon be stalled) waiting for it - at the very least get a list of the FM 'stakeholders'.
The main problem is that a Grid Coverage merge could quite possibily "step on the toes" of the FM folks (see the IRC discussion linked above). Trying to do the Grid Coverage merge and FM merge at the same time is almost certainly going to cause problems, so it seems like we should either:
a) merge current trunk (I believe the main changes are changes to expression - correct me if I'm wrong) with Grid Coverage Branch + Renderering Improvments - this would be a 2.3 release.
2.4 would then be 2.3 (ie. coverages) + FM.
OR
b) wait for the FM merge to occur (current trunk + FM = 2.3) then merge the Grid Coverage stuff in later (2.4 = trunk + FM + Grid).
There's other options, but I thought I would just throw this out so that the FM folks could start talking. Whats the plan? (In terms of those working on it, and those "waiting" on it) Is doing a Grid merge going to cause problems? If so, what do we do?
I dont think there's a pressing need "right now, today" to merge the grid stuff in (I could be wrong, though), but I know a lot of people have been waiting for it for a while.
dave
ps. Jody's kindly offered (free-as-in-beer-and-as-in-speech) FM walk-throughs all this week on IRC.
pps. There is starting to be a fairly large divergence between 2.2.x and trunk. This is making it difficult to move 2.2.x patches to trunk - not all bug fixes are finding there way to trunk. This seems to indicate that we should kick out a 2.3 fairly soon.
ppps. Justin has said that the FM branch is basically a re-write of the geotools core. It certainly makes sense to call the end result "geotools 3" to recognize this.
--
Justin Deoliveira
jdeolive@anonymised.com
The Open Planning Project
http://topp.openplans.org