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