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 ​#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

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