The third meeting of the FDO PSC will take place on 10-24-2007.
Meeting Chair: Greg Boone
Location: The meeting will be held on IRC at #fdo
- Incubation Status
- Review contributor agreement status
- Updated Source Code Provenance Review
- Proposed release schedule for FDO 3.3.0 (see FDO Road Map)
- RFC XX - WMS FormatType -- TDB
- Thirdparty Source Code Updates
- GDAL/OGR 1.4.3
- Adoption of New FDO Providers
- FDO provider for NEN1878
-->| orest (email@example.com) has joined #fdo <gregb> Hi Orest -->| rbray (firstname.lastname@example.org) has joined #fdo -->| danmo (email@example.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@188.8.131.52) has joined #fdo -->| FrankW (firstname.lastname@example.org) 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 (email@example.com) 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 184.108.40.206/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.