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