Project Steering Committee - Home

Meeting Info

The third meeting of the FDO PSC will take place on 10-24-2007.

Meeting Chair: Greg Boone

Universal Time: ​http://www.timeanddate.com/worldclock/fixedtime.html?year=2007&month=10&day=24&hour=17&min=0&sec=0

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

Agenda

• Incubation Status
• Review contributor agreement status
• Updated Source Code ​Provenance Review
• Proposed release schedule for FDO 3.3.0 (see FDO Road Map)
• RFCs
  • RFC XX - WMS FormatType -- TDB
• Thirdparty Source Code Updates
  • GDAL/OGR 1.4.3
• Adoption of New FDO Providers
  • FDO provider for NEN1878

Transcript

	-->|	orest (n=chatzill@12.160.193.229) has joined #fdo
	<gregb>	Hi Orest
	-->|	rbray (n=chatzill@adeskout.autodesk.com) has joined #fdo
	-->|	danmo (n=dmorisse@157-146.svr.royaume.com) has joined #fdo
	<gregb>	Hi Bob
	<rbray>	Hey Greg
	<gregb>	So, I see Orest and Bob, who else is online?
	<mloskot>	Hi all
	<gregb>	Hi Mateusz
	-->|	RobertF (n=RobertF@12.160.193.229) has joined #fdo
	-->|	FrankW (n=warmerda@dpc674728121.direcpc.com) has joined #fdo
	* mloskot	is calling Frank
	<mloskot>	ah, cool
	-->|	jasonbirch (n=jasonbir@osgeo/member/jasonbirch) has joined #fdo
	* danmo	here
	* FrankW	multiplexes between foss4g and fdo meeting. :-)
	-->|	HarisK (n=chatzill@84-255-254-95.static.dsl.t-2.net) has joined #fdo
	<HarisK>	Hi
	<gregb>	Orest is asking if his posts can be seen....
	<orest>	Hi.
	<orest>	Hi Greg.
	<gregb>	There we are
	<RobertF>	Hi
	<gregb>	I think the entire PSC is here, shall we begin?
	<orest>	Sure.
	<jasonbirch>	Howdy
	<gregb>	The first topic should be incubation
	<mloskot>	yup
	<gregb>	I have received a new contributor agreement from Bon
	<gregb>	Bob
	<gregb>	I am reviewing it and will post to the internals alias shortly
	<gregb>	We then will need to ensure that all appropriate parties have signed
	<rbray>	Greg, we need to review that and motion to adopt them.
	<gregb>	Agreed
	<gregb>	I will make that motion once all parties have had a chance to review
	<mloskot>	Perhaps, i've lost the subject, but I've not signed FDO or OSGeo Foundation contributor agreement
	<mloskot>	that's listed here
	<mloskot>	http://fdo.osgeo.org/developer.html
	<gregb>	Once the new agreement is adopted, you will be expected to sign
	<gregb>	That link is out of date
	<mloskot>	understood
	<gregb>	The second issue for incubation is the provenace review
	<gregb>	I have updated the online document
	<gregb>	We have some outstanding issues surrounding raster test data
	<gregb>	I am unsure how to proceed on those files
	<FrankW>	I am willing to "speak on behalf of" a bunch of the files.
	<FrankW>	For others, it might be sufficient for an ADSK rep to state they believe they have rights to use and redistribute them even if detailed history is unclear.
	<FrankW>	And we should make it clear that detailed licenses are not clear for the files, though we believe we have rights to redistribute.
	<gregb>	That may also prove difficult
	<gregb>	The sources of some files have become lost
	<FrankW>	What we aren't willing to "speak for" we should remove and re-engineer the tests to use other similarly organized data.
	<gregb>	Agreed
	<FrankW>	Was ADSK careful that it had rights to use and distribute it's internal test data?
	<gregb>	I would state that there is some possibility that some files were not validated
	<FrankW>	I will update the prov. review with regard to files I'm comfortable with speaking on behalf of.
	<gregb>	Great
	<gregb>	I have updated the incubation status page as well as the coding standards reference
	<FrankW>	And I'm willing to do some engineering to replace some other test files with safe to distribute ones that achieve the same unittest functionality.
	<FrankW>	though there may be limits. :-)
	|<--	rbray has left irc.freenode.net (Read error: 104 (Connection reset by peer))
	<gregb>	We need to revisit the incubation page once the raster image history is addressed
	<FrankW>	Are the non-raster data files all sanctionable?
	<gregb>	I believe so, but the SHP data also should be re-checked
	<gregb>	Just to be sure
	<RobertF>	Didn't we check on that before submitting to OS?
	<gregb>	Yes, but a secondary check wouldn't be a bad idea
	<gregb>	We dumped a lot of data into SVN in a hurry
	<gregb>	Until we get a handle on the testdata, we should not distribute the testdata tar files
	<RobertF>	That was not my understanding and it needs to be corrected.
	<gregb>	Agreed. I will take care of re-checking the SHP data
	<FrankW>	gregb: I don't think we need to strip stuff out in advance of review and remediation.
	<FrankW>	Though I may not be as risk adverse as ADSK. :-)
	<gregb>	Agreed. but the testdata is released as a separate tar file now
	<FrankW>	Ah, I didn't realize that.
	<jasonbirch>	Which is a good change...
	<gregb>	Wwe can delay the release until we are comfortable
	<jasonbirch>	Yeah, most people don't run the tests anyway ;)
	<mloskot>	lol
	<gregb>	(Actually, it is a number of tar files, one for each provider)
	<gregb>	:-)
	<gregb>	Can we discuss the FDO readmap?
	<gregb>	roadmap
	<mloskot>	+1
	<gregb>	The fdo.osgeo.org site has been updated to contain the details of the 3.3.0 release schedule
	<orest>	Yes, saw that.
	<gregb>	With dates for an alpha, beta, candidate, etc
	<mloskot>	http://fdo.osgeo.org/roadMap.html
	<RobertF>	This was just a proposal.
	<gregb>	What is the impression of the PSC?
	<mloskot>	I have to confess, I like the idea about Beta in Dec :-)
	<RobertF>	There is also the request to have a 3.3.0 in october and 3.3.1 in February for MGOS.
	<gregb>	Agreed
	<FrankW>	looks ok to me.
	<jasonbirch>	Heh, so MapGuide is going to release with a pre-alpha version of FDO...
	<mloskot>	gregb: my impression is "it works for me" and "gives a chance to bring updated PostGIS provider with 3.3.0"
	<gregb>	They will put out their beta with our alpha
	<RobertF>	That's the problem for MGOS. They can't release on Beta and they are targetting 3.3 branch.
	<RobertF>	Has this been agreed with MG team?
	<mloskot>	Perhaps I don't understand the connection between MGOS and FDO well, but MG is a client so it should follow the roadmap of FDO, but not the other way. Am I correct?
	<mloskot>	I just would like to be explained.
	<jasonbirch>	MapGuide can choose to release with FDO trunk or alpha if it wants.
	<FrankW>	It is an important client that had best support well.
	<jasonbirch>	I have a feeling that Tom wouldn't be happy with it though.
	<jasonbirch>	Given his stance on GEOS3
	<jasonbirch>	I think the timing on the betas and rcs is a bit wide...
	<gregb>	Well, I do not believe that the release schedule for FDO can be advanced beyond the postyed dates
	<jasonbirch>	Is this because of additional functionality?
	<jasonbirch>	Or because of internal ADSK QA schedules?
	<orest>	What's the current date for MG beta?
	<jasonbirch>	A week ago :)
	<orest>	I missed it!
	<RobertF>	They shipped on S013 build which we didn;t post yet.
	<jasonbirch>	didn't happen :)
	<gregb>	I am not in favour of releasing FDO without a beta
	<RobertF>	I agree.
	<gregb>	and we need to leave time between the beta and candidates for testing, etc
	<orest>	Agree.
	<jasonbirch>	Me neither
	<mloskot>	MG 2.0 is planned to Nov 30
	<mloskot>	as I see.
	<gregb>	That is very tight for us.
	<jasonbirch>	I don't think the roadmap is accurate mloskot
	<mloskot>	jasonbirch: ok
	<jasonbirch>	Too bad Bob left...
	<jasonbirch>	The MapGuide timing is 2 weeks between betas and RCs generally...
	<gregb>	He lost his connection
	<jasonbirch>	Snowstorm probably ;)
	<mloskot>	Folks, perhaps we can collect comments/votes for the roadmap as a preliminary voting and if we like it, we can discuss it with MG team
	<mloskot>	apply changes
	<mloskot>	re-vote
	<HarisK>	I think once was already mentioned relationship between FDO version and provider's version's
	<gregb>	At this point it is November, to advance the cycle, we would need to skip the alpha
	<jasonbirch>	http://mapguide.osgeo.org/releaseprocess.html
	<gregb>	And possibly one of the cadidates
	<HarisK>	Am I right if I am looking at it that provider's has it's own development rate
	<mloskot>	gregb: my question is, does it (one month advance) change anything ?
	<mloskot>	stable release is planned to march 2008
	<mloskot>	if MG stable is planned earlier, I don't think skipping changes anything here
	<gregb>	It is a matter of testing
	<jasonbirch>	Yes...
	<mloskot>	ok
	<FrankW>	HarisK: I think a provider could have some of it's own releases within a given FDO stable version framework. Is that your point?
	<HarisK>	yes and also supporting different version's of FDO spec
	<mloskot>	huh, challenging
	<FrankW>	HarisK: I'm ok with a "trunk" provider retaining compilability under older versions of FDO.
	<gregb>	Ok, so is there any proposal to change the posted schedule?
	<jasonbirch>	It would be nice if MG and FDO weren't on the same development-push cycle, but I don't see that happening soon.
	<RobertF>	This was suggested before but it does require lot of time to maintain multiple branch.
	<gregb>	If not, we can vote to adopt and bring it to the MapGuide team for discussion
	<jasonbirch>	Somehow we need to figure out what FDO needs to do. I can't speak to test cycles, but would cutting the time between iterations to 2-3 weeks help?
	<mloskot>	gregb: +1
	<gregb>	2 weeks is not much time.
	<gregb>	3 maybe ok
	<mloskot>	I agree with gregb
	<jasonbirch>	Either case, I don't think it helps MapGuide. This version of OS is likely to ship with an untested version of FDO...
	<jasonbirch>	Either that or be delayed.
	<gregb>	Agreed
	<HarisK>	are there any breaking changes in 3.3 ?
	<gregb>	There is one known issue with WMS
	<mloskot>	new GDAL
	<jasonbirch>	New GDAL breaks stuff?
	<mloskot>	and new providers
	<gregb>	I have emailed the internals group with detailes on RFC 10
	<HarisK>	but no new FDO spec ?
	<FrankW>	new gdal should not break stuff.
	<mloskot>	jasonbirch: no
	<gregb>	New providers are ok
	<HarisK>	I don't see new providers as new version's of FDO
	<jasonbirch>	No, me neither...
	<FrankW>	HarisK: by breaking do you mean api changes of any kind or just changes that would break old code?
	<FrankW>	I think most api adjustments have not had serious backward compatability issues.
	<HarisK>	I mean if like api changes which will not allow older providers to run
	<HarisK>	yes, ok
	<gregb>	A recompilation of the providers will be required for use with 3.3.0
	<gregb>	If I understand correctly
	<gregb>	To move the meeting along, is there agreement on the schedule?
	<FrankW>	I'm ok with it.
	<jasonbirch>	Sure. As long as you are convinced that advancing the schedule would add unacceptable risk, then I'm OK iwth it.
	<gregb>	Robert? Can you comment?
	<HarisK>	I was also thinking that we can do it quicker if neede for MG
	<mloskot>	I'm OK too
	<HarisK>	Changes in 3.3 as far as I know are not big, mostly addition's which will not change existing providers
	<mloskot>	HarisK: so you mean it should be safe for MG to use pre-release version of FDO in their release, do I understand it correctly?
	<HarisK>	No, I thaught that we could perhaps speed up regarding 3.3
	<orest>	But any place where MG uses new additions would require enough time for testing.
	<jasonbirch>	Only if it's accepted that there will be a 3.3.1 for March I think...
	<mloskot>	HarisK: I see
	<HarisK>	if some specific provider need more time later than he can be released again
	<gregb>	I am warry stating that anything is safe, without some time for testing
	<gregb>	The risk is there
	<gregb>	We could do a release candidate in December
	<gregb>	If that goes well, release 3.3.0 in January
	<mloskot>	so, generally, you mean we're flexible but what we are supposed to agree with now?
	<RobertF>	There will be changed after January - they will go in 3.3.1?
	<mloskot>	The current written roadmap or this new changes?
	<gregb>	RobertF: Yes
	<mloskot>	I see
	<jasonbirch>	Point releases generally shouldn't include new features, I think...
	<jasonbirch>	Large changes?
	<RobertF>	Then we probably need a 3.3.1 somewhere by March.
	<jasonbirch>	Additions? API changes? Bug fixes?
	<mloskot>	I think bug fixes and eventually some updates in providers only
	<gregb>	There should ne no API changes in a point release
	<RobertF>	Bug fixes only.
	<jasonbirch>	Works for me...
	<orest>	That's the way I understand it too - bug fixes only
	<orest>	But, is it the release date that is the issue? I thought it was mostly beta date that was the issue?
	<FrankW>	Note, we have made API compatible feature improvements within providers in point releases in the past. Not sure if we will keep doing this or not.
	<mloskot>	I agree, but if we are changing the roadmap by skipping some milestones, then
	<mloskot>	perhaps we could leave some backdoors to let updates in providers
	<mloskot>	exceptionally for this roadmap
	<jasonbirch>	I don't think that we should constrain providers to not change at all in point releases. Non-API changes should be OK.
	<mloskot>	+1
	<gregb>	Agreed
	<jasonbirch>	But major features should be avoided too, because testing requirements would skyrocket :)
	<mloskot>	Agreed
	<orest>	Right, improvements to existing functionality is ok, but not new functionality / capability.
	<gregb>	Agreed
	<mloskot>	Summarizing:
	<mloskot>	- no provider's API change
	<mloskot>	- no new features
	<mloskot>	EOF
	<jasonbirch>	So. What's changing in the release cycle then?
	<gregb>	The proposal is a release in January
	<gregb>	With a candidate in December
	<jasonbirch>	Beta in November then?
	<gregb>	Yes. Alpha may be possible if we go out with it this week
	<jasonbirch>	Any chance of getting GDAL 1.4 into that?
	<orest>	It's kind of loose to say November / December, etc. Don't we need to pin down calendar day or week?
	<jasonbirch>	I mean 1.4.3? Does it exist yet?
	<gregb>	1.4 is in the alpha. But not 1.4.3
	<FrankW>	1.4.3 does not exist yet, but one hopes it will within a few days.
	<gregb>	We can assign firm dates to the releases
	<gregb>	We probably can do that offline (fdo-internals)
	<jasonbirch>	I think that as long as we have general agreement, it's OK for Greg to come up with the firm dates?
	<gregb>	I can do that
	<gregb>	I will work on getting the current build posted as an aplha as well
	<jasonbirch>	Unless Haris has something major going on with FDO that he wants to fit in? I don't think that either mloskot or FrankW do right now?
	<HarisK>	no
	<FrankW>	neither I.
	<mloskot>	neither I
	<gregb>	I motion that we adopt the proposal to release 3.3.0 in January, with a candidate in December, and a beta in December
	<gregb>	beta in November
	<jasonbirch>	Seconded and +1
	<mloskot>	+1
	<HarisK>	+1
	<FrankW>	+1
	<orest>	+1
	<gregb>	The motion is carried
	<gregb>	I will come up with the dates and send them out
	<mloskot>	gregb: thanks!
	<gregb>	Do we have time to discuss new providers?
	<jasonbirch>	I've got another 15 minutes :)
	<orest>	I have time.
	<FrankW>	I have time.
	<HarisK>	me too
	<gregb>	There has been some interest on a provider for NEN1878
	<mloskot>	I have time
	<gregb>	We are waiting for some more information.
	<gregb>	Is there anything we need to do here?
	<FrankW>	Is there a committer willing to do evaluation of the NEN1878 provider?
	<gregb>	I have volunteered to provide guidance, but a review may need more attention
	<HarisK>	I can do it
	<HarisK>	I understand they already have a working verison of it
	<gregb>	We should touch base with them again to encourage movement on the RFC
	<orest>	Do we have a detailed list of capabilities yet?
	<gregb>	No
	<HarisK>	I saw just one email explaining what it is
	<FrankW>	I'm pleased to leave this to gregb and HarisK. If the provider looks good we can hopefully bring in the developer as a committer.
	<HarisK>	Cadastral data exchange file
	<gregb>	Agreed
	<HarisK>	ok
	<mloskot>	Agreed
	<gregb>	Are there other providers in development that we know about?
	<HarisK>	or not know :)
	<gregb>	lol
	<FrankW>	Are folks at 1spatial working on provider(s)
	<orest>	I will be sending out a discussion soon on work we're starting on SQL Server 2008, which will have native spatial data types.
	<FrankW>	(that was supposed to be a question)
	<jasonbirch>	orest: will that be proprietary?
	<orest>	No.
	<jasonbirch>	Oh, cool...
	<orest>	At least until the API from Microsoft becomes public.
	<gregb>	FrankW: I am not aware of any effort from 1Spatial. I will touch base with Peter R to verify
	<HarisK>	I know they are using King.Oracle
	<gregb>	Concerning King.Oracle, we will need the copyrights adjusted for incubation to pass
	<jasonbirch>	? what are they now?
	<HarisK>	Can we discuss little bit on posted Future stuff?
	<gregb>	josonbirch: they are missing at this time
	<orest>	FYI: Bob cut out due to losing their internet connection. Unfortunately, now he is in another meeting.
	<jasonbirch>	Oh, that might be a problem :)
	<gregb>	We can discuss futures
	<gregb>	Where do you wish to start?
	<HarisK>	FDO Client Utilities
	<HarisK>	that name doesn't sound right to me
	<gregb>	Orest has published a working paper
	<jasonbirch>	Got to go... thanks!
	<gregb>	A starter document
	|<--	jasonbirch has left irc.freenode.net ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]")
	<HarisK>	yes I haven't invested enough time into it
	<gregb>	Orest, do you plan to update that doc?
	<RobertF>	I think we should allow more time before we discuss futures.
	<orest>	The idea is to start with some high level options and let folks add to it.
	* FrankW	things futures is a bit much for this meeting too.
	<orest>	I was going to wait for others to comment before adding more to it right now.
	<HarisK>	yes ok, I redraw topic
	<HarisK>	I will pst on mailling list
	* mloskot	's futures include postgis provider improvements and completing unit tests
	<FrankW>	HarisK: sounds good!
	<gregb>	ok
	<gregb>	Are there other topics for today's meeting?
	<FrankW>	WMS provider issue?
	<gregb>	Yes
	<gregb>	I posted a note to internals describing the issue
	<gregb>	Is there any feedback?
	<FrankW>	I'm ok with the proposed solution.
	<gregb>	Orest?
	<gregb>	Any other comments?
	<orest>	I'm ok with it.
	<mloskot>	I'm ok too
	<gregb>	If not, I motion that RFC 10 be updated as proposed.
	<gregb>	And implemented as stated
	<orest>	Did anyone double check that the current version of the WMS provider will in fact skip over that new element?
	<gregb>	No. I believe that has not been validated
	<gregb>	I do not see a problem, but testing is required.
	<orest>	I wouldn't mind getting it validated just to be sure.
	<gregb>	Ok. Let's postpone the vote until that time
	<FrankW>	ok
	<gregb>	We can do it on fdo-internals
	<mloskot>	ok
	<FrankW>	ok
	<gregb>	Are there any other topics for discussion?
	<mloskot>	we've cleaned the meeting agenda
	<mloskot>	I don't have any other topics myself.
	<gregb>	If not, I propose we djourn
	<FrankW>	+1
	<gregb>	+1
	<mloskot>	+1
	<orest>	+1
	<RobertF>	Since I can't vote...see you next time.
	<gregb>	Thanks everyone. I will ensure we do these more regularly
	<HarisK>	Greg +1, good job
	<mloskot>	Thanks Greg!
	<HarisK>	thanks
	<HarisK>	bye
	<orest>	Good meeting. Thanks everyone!
	<gregb>	You are welcome. Bye
	<orest>	Bye.