Project Steering Committee - Home

Meeting Info

The next meeting of the FDO PSC will take place on 03-12-2008.

Meeting Chair: Greg Boone

Universal Time: ​5:00 pm

Location: The meeting will be held on IRC at ​#fdo

Agenda

• Review of the status of the 3.3.0 release
  • Proposed 3.3.1 point release of FDO
• SQL Server Spatial Provider update
• PostGIS Provider update
• Proposed FDO API enhancements
  • ​FDO RFC 15
• Formalizing the FDO Release Process
  • ​FDO RFC 14
• Moving towards the next release of FDO. FDO 4.0(?) and beyond.
  • ​FDO Client Utility Futures
• Encouraging new developer members to join the community.
  • Are there FDO Provider development efforts underway that need our support?
  • How can we encourage new open source code to be added to the FDO domain?

Transcript

<gregboone>Hi All. The meeting will start shortly. I want to give others a few moments to join
<osgeobot> fdofeed: PscMeeting200801 edited by mloskot <http://trac.osgeo.org/fdo/wiki/PscMeeting200801>
<gregboone>Well... Let's start and others can join as they see fit
<orest>We're still missing three people.
<gregboone>Yes... I don't know if they will join today
<gregboone>Haris looks doubtful
<orest>Yes, I saw his email.
<gregboone>Jason should be here. I will ping him.
-->|jasonbirch (n=jasonbir@199.175.138.1) has joined #FDO
<gregboone>I also pinged Bob
<gregboone>Hi Jason
<jasonbirch>allo
<jasonbirch>sorry, was distracted. I'm still running mg 0.91 on my public server and it's getting hammered because of recent press.
<gregboone>No worries. We are just starting.
<gregboone>I will start off and congratulate all those who helped make the FDO 3.3.0 release a success
<gregboone>3.3 was included in MapGuide 2.0 and looks to be fairly stable and healthy
<jasonbirch>Agreed. Pretty brave of those MG guys to release with RC FDO ;)
<gregboone>True
<orest>Extra QA!
<jasonbirch>lol
<gregboone>Note that I created a 3.3.0 branch for that release. It is pretty much a dead end branch at this point
<gregboone>It is meant to support MapGuide 2.0 only
<gregboone>I also created a 3.3.1 point release branch
<jasonbirch>New features in 3.3.1?
<gregboone>At this moment, the only known customer of this branch will be Autodesk Map and MapGuide
<gregboone>This branch will only contain high priority fixes for issues found in 3.3.0
<jasonbirch>I'd like to convince Tom to do a 2.0.1 of MGOS too, mostly for Fusion improvements. But I saw a couple SDF fixes that looked interesting.
<FrankW>Is 3.3.1 a suitable place to fix build quirks too (such as the #273 64bit ticket)?
<gregboone>I felt a branch was necessary was necessary for 3.3.1 so that continued development could occur on the trunk
<gregboone>FrankW: God question
<gregboone>* good
<FrankW>The fix is somewhat useful for general use of FDO but has limit value to mapguide which isn't 64bit anyways.
<gregboone>Right. 
<gregboone>Unless a customer has indicated they want to use the 3.3.1 branch, it may make sense just to leave it in the trunk
<osgeobot>fdofeed: PscMeeting200801 edited by warmerdam <http://trac.osgeo.org/fdo/wiki/PscMeeting200801>
<FrankW>ok
<jasonbirch>Would 3.3.2 (if it came along) be based on trunk or 3.3.1?
<jasonbirch>Ie, are we going to 3.4 on trunk?
<FrankW>But 3.3.1 is basically the stable release we would expect any non-mapguide FDO client to also use, right?
<gregboone>I would say the trunk
<gregboone>FrankW: Yes
<FrankW>To be honest, I had expected there would be a 3.3 branch and 3.3.0/3.3.1 tags on that branch.
<jasonbirch>That kinda makes sense to me too
<gregboone>I am open to exploring that idea.
<FrankW>That does seem to be implicit in the RFC 14 release process document, though not spelled out.
<jasonbirch>Branches make more sense though if you're allowing ABI changes on point releases.
<FrankW>Otherwise it is hard to ensure that point releases contain only bug fixes (if we make them branches off trunk each time)
<FrankW>!
<gregboone>In the past we have not formally built off of tags, but of of branch versions
<gregboone>True
* FrankW hopes we will only entertain ABI changes in point releases under extreme conditions. 
<mloskot>tag is nothing different than a branch + remembered revision
<jasonbirch>It's psychological mloskot
<jasonbirch>:0
<FrankW>Right, but we think of branches as dynamic things, and tags as snapshots. It's a mental thing. IMHO
<gregboone>So how can we move from the two brach strategy to one
<gregboone>?
<gregboone>We could have to rename 3.3.0 -> 3.3
<mloskot>My point is that tags are useful and safer way of managing snapshots
<jasonbirch>Or 3.3.x
<gregboone>I see
<mloskot>3.3
<FrankW>Well 3.3.1 is effectively the 3.3 branch I think. So I would suggest renaming 3.3.0 as tags/3.3.0, and rename 3.3.1 branch as the 3.3 branch.
<FrankW>If that isn't going to be too disruptive.
<mloskot>FrankW: +1
<FrankW>Then "tag" 3.3.1 when we are ready to release it.
<FrankW>This is also the practice on projects such as GDAL, and MapServer.
<FrankW>(and GEOS)
<gregboone>I will give a conditional +1. Let me investigate and get back to the PSC.
<gregboone>I want to make sure our build processes can handle this easilty
<FrankW>ok
<gregboone>Orest: any objections?
<orest>No objections, but check the build process as you said.
<gregboone>ok
<gregboone>Let's move to SQLServer
<gregboone>I have posted a beta release for 3.3 and 3.2
<orest>Have you heard if anyone has tried the 3.2 build?
<gregboone>No. I tried it in Map, but that is all I know of
<jasonbirch>Oh, I dodn't realize there was a 3.2 build...
<gregboone>There was an announcement
<gregboone>Things are looking ok at this time. We know of a few issues but nothing too serious
<orest>It's there in case someone wanted to try it with 3.2-based clients such as MG 2008.
<jasonbirch>I can't bring up the minutes right now. SVN/Trac aren't playing nice for me.
<orest>I'm having problems getting to fdo.osgeo.org right now.
* FrankW is investigating...
<gregboone>We are still working towards a full SQLServer release later this year in conjunction with the Microsoft launch
<jasonbirch>Anyway...
<jasonbirch>I've played some with the SQL Server provider.
<jasonbirch>It's generally pretty good.
<jasonbirch>As long as you don't have invalid data.
<jasonbirch>:)
<gregboone>:)
<gregboone>orest: can you provide an update?
<orest>Yes, I'm kind of worried about invalid data.
<jasonbirch>Currently all it takes is one rogue Map user to mess up my MapGuide display :)
<orest>We fixed some issues with SRID handling on query. There was also supposed to be a fix for handling that correctly on insert - I think it was dropped.
<gregboone>orest: are we on schedule according to the RFC?
<orest>Invalid data, which can be stored and is flagged as such in the server, causes an exception from SQL if you try to use it in a filter.
<jasonbirch>And MapGuide always filters :)
<orest>Yes, it always filters. Current work around is to use the MakeValid function on SQL to set the data as valid.
<orest>I've asked exactly what that function does to your data, but haven't heard back yet.
<orest>I think we're on track based on the phases described in the RFC. Next step is apply schema support for existing schema, and figure out processing of invalid data.
<jasonbirch>I haven't tried setting up a view of IsValid data, and seeing whether it respects spatial indices yet.
<orest>My guess is that it would not, but worth a try.
<gregboone>Great. There has been a lot of expectation generated in the community
<gregboone>It looks like this provider will be heavily used
<orest>I've found SQL 2008 fairly stable considering that the spatial support is a version 1.
<gregboone>How about the PostGIS provider? Has there been any movement in that area? I know an outside company was looking to invest resources
<jasonbirch>Haven't heard from Bruno recently...
<gregboone>They have not been vocal lately
|<--mloskot has left freenode ("Leaving")
<FrankW>I don't think it is worth holding back on 3.3.1 for those improvements if that is the question.
<orest>You scared off mloskot.
-->|mloskot (n=mloskot@osgeo/member/mloskot) has joined #FDO
<FrankW>:-)
<FrankW>trac is back, btw.
<gregboone>Autodesk has really suspended efforts on PostGIS in expectation that Bruno would run with the PostGIS changes
<jasonbirch>No, these are post 3.3.1 provider-specific releases
<jasonbirch>Time to ping Bruno I guess. I can do that...
<gregboone>That would be great
<gregboone>I still have to release a document outlining the findings we made in our experience using the provider
<orest>Bruno?
<gregboone>we as in Autodesk
<mloskot>gregboone: which one, there seems to be two providers in use
<mloskot>first based on Generic RDBMS
<mloskot>and second based on King Oracle approach
<gregboone>The only PostGIS provider code base being maintained in the Providers/PostGIS code base
<mloskot>ah, ok
<mloskot>I'm asking because near Sept someone from Autodesk announced that the GRDBMS-based provider runs too
<gregboone>Well, it does run, based on on initial work that was completed
<mloskot>right
<gregboone>But that code does not exist in OpenSource
<mloskot>right, it lives in old SVN, my private branch
<mloskot>anyway, seems it's a closed subject
<gregboone>Ok. Let's ping Bruno Scott and see what is on the go
<jasonbirch>will do.
<gregboone>Concerning RFC 14. What is the status of this RFC?
<FrankW>RFC 14 - the release process?
<gregboone>I think it needs additional work?
<gregboone>Sorry RFC 15
<gregboone>I got my RFC's mixed up
<orest>RFC 15? I just sent an email today to Maksim to see if he's done anything recently on this RFC. He hasn't changed the doc yet based on email thread on fdo-internals.
<jasonbirch>Yes, I think it's something that is sorely needed, but the RFC needs to be updated with feedback.
<gregboone>OK. Let's have Maksim update the RFC and we can re-evaluate
<orest>I think the concept is good. We just need to get the spec right. What do others think?
<gregboone>I agree
<gregboone>On to RFC 14? The FDO Release process. I have heard back from Jason, but not others. What do people think?
<mloskot>The release process and versioning scheme works for me.
<FrankW>I'm generally supportive but have not reviewed it in the detail I ought to.
<mloskot>Are we going to rotate release managers every 6 months?
<FrankW>Given our relationship to the MapGuide project is a six month fixed release cycle really the best choice?
<gregboone>mloskot: probably not
<jasonbirch>Heh.
<gregboone>FrankW: 6 months in an idea
<gregboone>I am not sure of the practicality
<jasonbirch>I think it's probably realistic given ADSK's availability cycle though. :)
<gregboone>It would be easier to determine an appropriate cycle if we had other customers pushing for functionality/fixes
<mloskot>Do we consider that a release manager can be selected from the community?
<FrankW>I presume the "heavy weight" process relates to major releases (3.3, 3.4) not the point releases, right?
<FrankW>A release manager *could* come from outside ADSK, but I doubt that would be the case with the possible exception of bug fix releases.
<mloskot>The list of tasks seems to be pretty big, so it will require significant amount of time, so perhaps only full time manager is an option.
<gregboone>mloskot: Yes. But in all practicality, someone from Autodesk will have to assume the role until we gets the build process moved off of Autodesk servers
<mloskot>That clarifies my concerns.
<mloskot>OK
<jasonbirch>
And the hypothetical QA/website teams form :)
<gregboone>LOL
<gregboone>That is true
<FrankW>I assume that there is a formal QA process inside ADSK, and that outside QA is mostly informal use of the betas, and such. Is that right?
<gregboone>Correct
<FrankW>There is no reason outside folks can't run the regression tests in different environments.
<FrankW>I'd like to see more of that in the future.
<FrankW>(the test suites in the source tree)
<jasonbirch>And BuildBot...
* mloskot supports this idea as an important factor for building the FDO community
<gregboone>BuildBot support would be nice
<gregboone>We need someone to make that happen
<orest>Community input on test suites would be good.
<mloskot>I did it some time ago
<mloskot>As you can see, FDO is configured but offline - http://buildbot.osgeo.org/
<FrankW>I think mloskot can refresh the buildbot support when his availability improves. :-)
<gregboone>mloskot: Why can't this be started?
<FrankW>We do have the disk space on the buildbot server now which was an issue for a while.
<mloskot>I turned it off because of a few problems:
<mloskot>- lack of disk space we experienced
<mloskot>- problems with SVN robustness, we experienced a few months ago
<gregboone>We also would need the build to package the tar files appropriately
<mloskot>- not much feedback from the team about need of Buildbot (I announced on the list but nothing happened)
<FrankW>buildbot is not for preparing packaged releases - it is for a build and smoke test.
<mloskot>etc.
<gregboone>Ok
<mloskot>Completing Frank's words, packages can be prepared with simple scripts, as it's done for GDAL
<gregboone>Well, I am in favor of turning it on. Let's see what happens
<mloskot>gregboone: OK, I will do it during the weekend
<gregboone>mloskot: that process should be automated
<mloskot>We are good regarding the disk space now
<FrankW>As for packaged releases, I'm interested in having FDO in in OSGeo4W at some point. I believe some folks at DMSolutions will attempt this from the MapGuide 2.0 binaries.
<mloskot>FrankW: am I correct?
<FrankW>mloskot: yes
<mloskot>gregboone: it is automated for GDAL
<jasonbirch>mloskot: are you hitting osgeo directly, or the mirrored svn?
<mloskot>gregboone: http://download.osgeo.org/gdal/daily/
<gregboone>mloskot: Are all thirdparty components/providers building as part of buildbot?
<mloskot>jasonbirch: directly
<mloskot>gregboone: yes, and that's another issue, it takes long time to build
<jasonbirch>You're probably the one crashing the server then ;) (kidding)
<mloskot>1-1.5 hr
<gregboone>mloskot: it does
<mloskot>That's one of the reasons I had to turn it off
<FrankW>Yes, it is a very demanding library from a buildtime point of view.
<mloskot>Perhaps we can use incremental builds for now
<FrankW>We wouldn't want the auto-build-on-svn-commit turned on.
<mloskot>and see how it operates for us
<gregboone>Well, can't we have Thirdparty built only on demand?
<mloskot>gregboone: building with BB does not differ from how you build FDO on your computer
<mloskot>So, if there is an option/switch to achieve that, then BB can use it as well
<mloskot>I mean , 3rd party on demand
<gregboone>mloskot: let's discuss offline and see what can be done
<mloskot>[back to reasons} there was yet another one, we had huge number of WWW files in the repo, so it took ages to do svn update, so I turned the BB off
<mloskot>gregboone: OK
<gregboone>If so, incremental auto-build-on-svn-commit should be ok
<mloskot>right
<gregboone>Great! This is good news
<gregboone>We would need builds for trunk and the 3.3 branch
<mloskot>I think we can use the same scheme as GDAL: trunk + current stable branch
<mloskot>ok, I'm taking this task
<gregboone>What about Windows and Linux?
<gregboone>Is there a build for each? If so, which vrsions?
<FrankW>Given the demanding nature of an FDO build, I would suggest we get one buildbot slave working smoothly before adding too many cases.
<gregboone>FrankW: Which OS would be supported first?
<FrankW>In my (indirect) experience keeping buildbot operational does require some effort, so we should avoid multiplying this too much.
<mloskot>gregboone: We host only Linux build machines on osgeo infrastructure
<FrankW>I would suggest linux is easiest.
<mloskot>but it's possible to connect external machines
<mloskot>BB is a distributed beast
<gregboone>Which version of Linux do we use?
<mloskot>AFAIR, Fedora Core 4
<FrankW>The telascience systems are mostly fedora core 4.
<gregboone>Ok.
<mloskot>FrankW: you mean one slave in general or one slave on osgeo machines?
<FrankW>I'm suggesting one slave in general for now, to see if it is useful, etc. before investing too much effort.
<orest>I have to leave, I have another meeting starting now.
<FrankW>(mloskot is also more busy than he might be willing to admit!)
<mloskot>FrankW: ok
<mloskot>FrankW: I agree, I usually take too much tasks than I can handle :-)
<gregboone>We need to get other resources (Such as myself) involved so that we have distributed knowlwdge
<FrankW>gregboone: you might want to review: http://wiki.osgeo.org/wiki/BuildBot_Configuration
<mloskot>I'm staying as "disappeared" from bigger hacking for next 1-1.5 months, but the Buildbot maintenance hasn't been overwhelming for me, so I'll keep my eye on it.
<jasonbirch>Bye orest
<FrankW>If we eventually have an OSGeo/telascience windows VM perhaps you could work with mloskot to setup an fdo buildbot slave on it.
<mloskot>gregboone: Here is description of GDAL BB instances: http://trac.osgeo.org/gdal/wiki/Buildbot
<mloskot>gregboone: I think we can clone it in some way
<mloskot>telascience-quick and telascience-stable
<mloskot>FrankW: there are 2 or 3 Builbot slaves installed on VM under Windows
<mloskot>I just turned them off, because of limited resources
<gregboone>Ok. Maybe we can continue this discussion offline.
<mloskot>OK
<mloskot>What's next?
<gregboone>Moving on.... So where is FDO headed? What do people think we need to do for the next major release?
<gregboone>Too bad orest had to leave
<jasonbirch>That's OK, we can make major decisions without him :)
<gregboone>:)
<mloskot>Trac is down for me
<mloskot>Anyway, I'd like to continue stripping Boost
<FrankW>trac is responding well for me right now.
<gregboone>We have some futures documents posted
<mloskot>#189 and #205
<gregboone>mloskot: sure
<mloskot>I submitted small improvements, but the minimal distribution is not ready yet
<gregboone>However, we have not had much feedback
<gregboone>We need to get feedback from MapGuide folks as well as Harris
<gregboone>Also, 1Spatial and the FME guys.
<mloskot>gregboone: incorporating idea explained in the #205 should speed up compilation significantly
<gregboone>mloskot: ok. This can be done in the trunk
<gregboone>We can port to 3.3 once the branches are sorted out
<mloskot>ok
<mloskot>What's next topic on the board?
<gregboone>We are still discussing futures
<gregboone>The next release of FDO
<gregboone>Well, maybe this topic is best suited for another meeting :)
<mloskot>I don't mind
<jasonbirch>What is missing?
<jasonbirch>I thought FDO was perfect? :)
<gregboone>haha
<mloskot>I also think the building community topic is a big one and probably best if we are all here
<gregboone>Last year there was discussion around a Client layer
<jasonbirch>I'd love to get some involvement from vertical app builders like Munsys to see what they would want.
<gregboone>That has not progressed
* mloskot is very happy jasonbirch loves PostGIS provider :-)
<jasonbirch>Doh...
<gregboone>jasonbirch: Agreed
<jasonbirch>I meant the API :)
<jasonbirch>Client layer, especially for projection and leveling of providers, would make me very happy.
<jasonbirch>Right now, amount of work just to see what providers support in client apps is painful.
<gregboone>I will be honest here and say we need non-Autodesk development resources to be heavily involved with such an effort
<mloskot>Have we considered participation of Google Summer of Code 2008?
<mloskot>I think projects like command line utilities would be very nice for GSoC
<mloskot>for students
<FrankW>yes, that would be a plausible sort of project.
<mloskot>not very complex, but with nice and observable results
<jasonbirch>Wish Haris was here...
<FrankW>I'm not sure that FDO has much visibility at the academic level though.
<FrankW>It may be hard to find students to get involved.
<mloskot>Perhaps Autodesk University could help in finding students?
<FrankW>But it isn't hard to post a few ideas.
<gregboone>I am open to hearing ideas and seeing where that leads us
<mloskot>I've seen Autodesk internships on the Web, may be some students could be asked/delegated to GSoC and FDO Open Source
<mloskot>These are very loose ideas
<mloskot>sorry if I'm discussing in the area being "not my business"
<gregboone>lol
<mloskot>:-)
<mloskot>As I do for GDAL and GEOS, I will spread the FDO GSoC on forums of Polish universities, etc.
<gregboone>OK. I guess this all ties into getting new developers interested in FDO 
<mloskot>but we need projects proposals
<gregboone>.. and growing the community
<gregboone>We need to grow our base and spread the word
<jasonbirch>Could be pimped as command-line tool to load to/from SQL Server Spatial...
<gregboone>Insn't that fdo2fdo?
<jasonbirch>Only on Windows.
<FrankW>I do worry about duplicating fdo2fdo, and "making fdo2fdo more usable/buildable" isn't going to be a fun SoC project.
<mloskot>The community subject is big and probably requires deeper/longer discussion. What about doing it on the fdo-internals and then make a meeting to discuss outcome?
<gregboone>mloskot: Ok
<mloskot>Plus, fdo2fdo is an existing application
<jasonbirch>I don't know how GDAL has built such a large community.
<gregboone>Well, fdo3fdo needs to move intro the trunk in order to be maintained
<FrankW>approachability, fill a critical gap, and 10 years...
<jasonbirch>Probably because it's usable without API too.
<mloskot>2 months is too short to taking up an existing software, explore it and add new functionality, especially for students
<mloskot>IMHO GSoC project is better to be simple, concise and finite
<FrankW>agreed
<gregboone>Yes
<gregboone>Ok all... maybe we should wrap this up? We can continue these discussions on fdo-internals?
<mloskot>I agree
<jasonbirch>Yes.
<gregboone>Thanks to all who attended
<jasonbirch>Next year, perhaps we can start thinking about GSoC earlier...
<gregboone>I will post the meeting notes
<gregboone>jasonbirch: Agreed
<mloskot>We have 2 weeks to think of project proposals
<mloskot>I mean, there is not much to prepare to attend GSoC. Usually, students should bring their ideas
<mloskot>So, the most important is to reach mass of students
<mloskot>with announcement
<mloskot>http://code.google.com/soc/2008/faqs.html#0.1_timeline
<jasonbirch>The OSGeo submission has been made, but we can still add ideas/mentors to our list.
<mloskot>ah, right
<gregboone>Just an FYI... Something I heard in the grapevine... We will have to consider what is needed in FDO in order to support VS2008
<gregboone>Whatever changes are required will only be made in the trunk
<gregboone>Maybe an RFC will be in order here
<jasonbirch>I haven't looked at the existing support...
<jasonbirch>You mean for building FDO, or using the API?
<mloskot>I'd not expect any significant fixes required
<gregboone>Build support mostly. 
<gregboone>We may need a couple of configurations
<gregboone>Also, do we release a version for 2005 and 2008?
<mloskot>gregboone: you mean binaries?
<gregboone>mloskot: Yes. If that is required
<mloskot>In both, manifests are available
<mloskot>so, I'd assume bins are compatible