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.
