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