[wiki:ProjectSteeringCommittee Project Steering Committee - Home] == Meeting Info == The next meeting of the FDO PSC will take place on 12-5-2007. Meeting Chair: Greg Boone Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?year=2007&month=12&day=5&hour=18&min=0&sec=0 Location: The meeting will be held on IRC at [irc://irc.freenode.net/fdo #fdo] == Agenda == * Incubation Status * FDO 3.3.0 Beta * GDAL 1.4.4 (fix ABI compatibility) * Boost (does it really need to be so big?) * Adding Sample Code to FDO SVN * Supporting Patched DLL Releases through fdo.osgeo.org * Proposal for provider for SQL Server 2008 spatial * How to kick start discussion on posted futures topics == Transcript == {{{ Hi Frank, Mat, Orest, Zak Hi Greg. Hi gregboone hi I guess it is that time. I was hoping Bob would make it. hi Hopefully he will join a little later OK. If we all are ready, we can start Do we have an agenda? * FrankW finds http://trac.osgeo.org/fdo/wiki/PscMeeting20071205 Yes. That is the agenda -->| CIA-26 (n=CIA@208.69.182.149) has joined #FDO Lets start with the first topic of discussion. Incubation status. OK. We have made some progress on that front. The contributor agreements have been approved I still need to talk to Bob concerning where to send them Bob said that he will be 5 minutes late. I am willing to accept them , but he may have a more centralized idea in mind for FDO/MapGuide We can defer this discussion until Bon joins After the agreement is accepted, we (contributors) are supposed to sign and fax them to Autodesk, am I correct? That is yet to be determined. ok but we have discussed that as an option Also to do with the incubation, I have the update of the King copyright info on my TODO list gregboone: is this just adding appropriate headers? Yes What about keeping information about original author of a file in header? Is this specified by incubation reqs? IOW, should we track information about file authors in comment block of a file? I am not opposed to that, but it is not on my radar at this time. The Copyright line should reflect the copyright holder, which might be the original author, if that is what you mean. So, Copyright information is the only required details Author is not, even if Copyright holder != Author well, it isn't required now. We (fdo) have no standards on headers as far as I know. understood FrankW: Once we get these items addressed, how can we move the process forward with the incubation committee? it's clear now. I just thought it's regulated by incubation somehow gregboone: danmo would do a review, and if he is happy propose a motion to graduate to the incubator. I've poked danmo in case he can pop in. There was the understanding that a couple of months of further incubation was required. Do you think we are now beyond that point? I think we are getting there. :) But we should still dot our i's and cross our t's with regard to provenance, contributor agreements etc. (IMHO) Daniel's opinion matters more than mine. I wouldn't object to FDO graduating at this point. The provenance is 98% complete. There is a few small issues with respect to GDAL and ArcSDE regarding their test data right I was trying to avoid pulling the data out, but it may just come to tahta (that) -->| rbray (n=chatzill@adeskout.autodesk.com) has joined #FDO I actively looked for replacement data, but have not yet found all I need Hi Bob Sorry I am late, hi all. Regarding contributor agreements, was there a new proposal on where they should be sent? No I think we decided to leave it alone and just coordinate. Still need to setup a Contributor Page To track all that. Should we discuss the details off-line? I am not sure this is the forum Yes that is fine. To end this thread, I will contact Daniel on nominating FDO for graduation Next in the Agenda is the FDO 3.3.0 Beta I have posted the tar files, updated the osgeo site and sent out a notice The beta is based on FDO build S019 was the notice very recent? I don't recall seeing it. It was sent to fdo-announce. ah, perhaps I am not subscribed. I'd encourage also cc:ing to fdo-internals. I will do that The MapGuide team plan to use the beta in their 2.0.0 beta The are integrating and testing now I believe I encourage all to try the beta and see if there are any issues. Any comments on the beta? cool, I see the builds include the python support. Perhaps can test a bit through that. It would be awfully nice if we could have fdo2fdo or some other tools in fdo binary releases for using fdo. * FrankW fails to poke haris... I'm testing FDO SVN with MG beta this week Yes. I believe there are a few bugs in the python wrappers. It would be good to test them further. still have to have test a lot of issues in the postgis provider. The King providers are not part of the beta That is unfortunate at this point. Any idea when they will be? I would like to see some movement there * mloskot has no idea What is holding them up? I was hoping Harris would move those providers forward and test Is the problem that they don't build easily? Obviously they are fairly widely used. Yes. Part of the issue is the build process I'm not sure but AFAIR Harris does not use SVN frequently but updates the King once a month or so We need to migrate the King build process to be consistent with the general build process Perhaps he has working/better version on his laptop, so he can just push it to the mainstream At FOSS4G he mentioned that a second developer was working on the Oracle provider And that a push was in the works However, I have not seen any activity I'm also interested in getting fdorastutil (http://svn.osgeo.org/fdo/trunk/Tools/fdorastutil/) into release builds. But I'm not exactly savvy about creating windows build stuff. I can look into that fdo2fdo is not in the SVN correct? Not yet, it seems. Put it would (when contributed) go into /Tools. Correct Yes tools is where we discussed putting it OK. Please forward an y ideas on contributions to the beta or the release process to me on fdo-internals ok Moving on to the GDAL 1.4.4 update I have submitted the update. It is part of the beta Do we need t do anything else for ecw/mrsid support? Do the updated plugins I provided work? I have not tested those. I'm still somewhat confused about this whole VC8/patchlevel dll issue. But if it doesn't affect folks using the dll's I produced then I guess it is ok. The SP1 issue? If it does, I either need toupdate or someone else has to build the plugins. gregboone: right gregboone: am I correct, that FDO/MG teams migrated to SP1 ? I believe we will need to build the plugins against SP1 In particular, folks shouldn't have to replace gdal14.dll with the one I made. Right Grr Perhaps I will consult with mloskot offline for advice on upgrading to SP1. ARe you using SP1 mloskot? More testing is required to finalize that belief FrankW: yes, I do (or I may beg mloskot to build the plugins) FrankW: no begging is needed, just tell me :-) I know that the SP1 redistributable was required to be installed at Foss4G in order for FDO to run. gregboone: right, VS2005+SP1 requires users to use new redist package SP1 is like new version of VS2005 :-) OK. Mat will look into generating new plugins for the GDAL provider yup Let us know if the GDAL binary shipped with FDO is ok to run with the plugins Lets move on to Boost The latest version has been submitted, but the footprint is large Ideas? 1. use system/user's version of boost 2. use bcp utility to generate subset of boost libraries 3. Windows users can use available binaries 4. Linux users have binaries too as packages The general rule for FDO Thirdparty is to ship all dependant library source code where possible Option 3 means boost lives in FDO tree ** Option 2 1, 3, 4 - external libs We can prune the boost tree to just include datetime and thread source We could always add new boost components as required I think that options 1,3, 4 are harder to maintain Honestly, using boost is very simple the only need is to specify min required version so, I can't see what's harder in 1,3,4 I do not doubt that, but I am concerned that changing the process may make the user experience more difficult agreed Can we take option 2 and make a more flexible solution a longer term goal? gregboone: yes First, we need to identify what libraries we use thread and datetime is it no others Second, we run bcp (http://www.boost.org/tools/bcp/bcp.html) to extract all of them with dependencies gregboone: ok, so these are two binary libraries but there is number of headers-only libs used I see at least I use them as I love them :-) in PostGIS provider I mean Maybe an offline discussion on fdo-internals will clear up what is required gregboone: I can volunteer to try to do it to generated minimal boost package for FDO If you could, that would be great gregboone: let me to grep through FDO sources and identify libraries and extract them Then, I will post to the fdo-internals about results Agreed Let's skip sample code and move the discussion to Patched DLLs ok gregboone: one Q to Boost, could you report ticket for this task? or I can report? Please file one ok On patches... I posted a patch to the FDO ArcSDE provider on a new pathes page on fdo.osgeo.org The idea was that I wanted to separate the download of release versions as opposed to patches Is there any feedback on this aoproach? gregboone: you are talking about: http://trac.osgeo.org/fdo/wiki/SubmitPatch ? https://fdo.osgeo.org/patches.html https://fdo.osgeo.org/patches.html Franks link was more geared towards code sun=bmission submission I was looking to formalize a release process other than a full release This is an approach to provide binary patches post release? Yes We had several requests for a patch If there are suggestions on improving this process, I am open to all ideas Do you think it is necessary to provide debug versions for patch binaries? No.... but I wanted to be complete. Would it be up to the normal "builder" (ie. you) to prepare these binary patches? The whole issue of releasing debug binaries could be re-evaluated Or is it intended that anyone can prepare one and post it? The normal builder should prepare these I'm just wondering if we should aim for "reduced pain for producer", or completeness. I want to maintain a consistent binary source sounds good to me. Ensures consistency. #189 On Debug binaries, should we be releasing them? Ticket #189: Generate minimal distribution of Boost libraries, http://trac.osgeo.org/fdo/ticket/189 gregboone: we can not release them if you mean release as publish debug binaries for Windows I mean debug versions of FDO binaries gregboone: we can not release them for Windows if built using VS, according to EULA attached to Visual Studio No.. I just meant the FDO binaries but compiled in debug mode, right? right that's what I'm talking about Ah... I'm not enamoured of distributing debug versions, but I don't object to it if I'm not the one preparing them. :-) "Redistributing debug VC++ programs is not permitted by the EULA. You can only do this for testing purposes internally. See the EULA for Visual Studio 2005." http://msdn2.microsoft.com/en-us/library/aa985617(VS.80).aspx Thanks for the link I will look at it and re-evaluate our process. gregboone: and Microsoft makes it hard to overcome by not publishing redistributable package of debug binaries Right you are. and by forbidding us to ship debug versions of runtimes etc. a lot of hacks ;-) We may have to remove links to our debug SDK tar files then. probably or may be you can leave them as for VS2005 owners only and not including debug runtimes That seems more confusing * mloskot is not a lawyer though We need a simple message Sorry to speed things up, can we discuss the RFC for the new SQLServer Provider? I have posted this as RFC 12 http://trac.osgeo.org/fdo/wiki/FDORfc12 I mentioned at the last PSC that Autodesk will contribute a provider for the new SQL Server 2008 spatial coming out sometime next year. We're working with a pre-beta version of it right now. RFC describes proposed capabilities and time-line. skimmed, looks great I am interested in hearing any feedback the community has. We are keen to make this provider a success Please post all comments to fdo-internals Does Haris have an SQLServer provider? Do we need to pick one that the PSC project "supports"? * mloskot has no technical comments, the RFC looks as complete and well-written. +1 We plan fairly complete capabilities: read/write, existing schema access and modification, all geom types and spatial operators available from the server, ... I certainly have no objections to RFC 12 We should support one as a supported PSC project Harris' provider does not support SQL Server 2008. At least not the native geometry format Ah, it is for non-spatial earlier versions? Gotcha Well, I'm all for rfc12. Our Product Manager spoke with Harris about our plans at FOSS4g and heard that he was supportive of this, would contribute after we posted our code. If there are no objections and we have general support, I motion that we accept RFC 12 Should rfc motions be happening on the mailing list? Can I get a seconder on that motion? :) It can happen on the mailing list if that is desired We take that practice in other projects though I haven't reviewed the fdo psc doc. I'll second. Mailing list would be good since not all members of psc made it today. I don't see that we are in a huge hurry, and it gives folks who aren't here an opportunity to comment. OK. I will make the motion there. Do we have time to discuss futures? hehe, no I see what's reasonable time to develop new FDO provider :) :) gregboone: what do futures include? I added this bullet. mloskot: any topic on the futures page We had posted a number of futures topics a few weeks ago ... BTW, would it be possible to write some details on time, etc into the 3.3.0 roadmap info? http://trac.osgeo.org/fdo/roadmap and haven't received too much feedback yet. I am most interested in the new client layer we discussed at FOSS46 I will take the roadmap update on my plate I don't think anyone has added comments yet. So, maybe today, this is just a reminder to review the futures topics and add comments, suggestions, additions, ... I don't have any comments to futures, but I'd like to see FDO utilities in future simple command line programs mloskot: Have a look at the first topic on client utilities. It may overlap what you're looking for. orest: yes, that's the document I'm referring I will give detailed feedback to it That would be great. Thanks. * FrankW digs into the client utilities topic... I encourage all PSC and community members to provide feedback on the client utilities topic so we can plan for the future releases of FDO SDF as a standard OSGeo File format is another topic for sometime. But it still doesn't seem to be about commandline/gui tools. Darn. SDF +1 Frank W: Go ahead and add commandline/gui topics to futures list. I will add the SDF topic as an agenda item for the next meeting. We have run past our alloted time. Could we use the fdo2fdo code to create some command line utilities. rbray: that was my thought at one point. isn't fdo2fdo in .NET ? Not sure if that is the most flexible approach. Shows what I know, it might be. Ah, I thought there was some sort of core that wasn't but I may be confused. I've yet to see the actual code. Well, I've got a date with my daughter to work on the snow fort... * mloskot too Well... I would like to wrap up the meeting. :) We can discuss sample code and utilities again at the next meeting agreed, Thanks all for joining Thanks! later folks! Frank W: Sounds like fun! I will update the PSC link with a list of action items Bye all }}}