The next meeting of the FDO PSC will take place on 03-12-2008.
Meeting Chair: Greg Boone
Universal Time: 5:00 pm
Location: The meeting will be held on IRC at #fdo
- Review of the status of the 3.3.0 release
- Proposed 3.3.1 point release of FDO
- SQL Server Spatial Provider update
- PostGIS Provider update
- Proposed FDO API enhancements
- Formalizing the FDO Release Process
- Moving towards the next release of FDO. FDO 4.0(?) and beyond.
- Encouraging new developer members to join the community.
- Are there FDO Provider development efforts underway that need our support?
- How can we encourage new open source code to be added to the FDO domain?
<gregboone> Hi All. The meeting will start shortly. I want to give others a few moments to join <osgeobot> fdofeed: PscMeeting200801 edited by mloskot <http://trac.osgeo.org/fdo/wiki/PscMeeting200801> <gregboone> Well... Let's start and others can join as they see fit <orest> We're still missing three people. <gregboone> Yes... I don't know if they will join today <gregboone> Haris looks doubtful <orest> Yes, I saw his email. <gregboone> Jason should be here. I will ping him. --> |jasonbirch (email@example.com) has joined #FDO <gregboone> I also pinged Bob <gregboone> Hi Jason <jasonbirch> allo <jasonbirch> sorry, was distracted. I'm still running mg 0.91 on my public server and it's getting hammered because of recent press. <gregboone> No worries. We are just starting. <gregboone> I will start off and congratulate all those who helped make the FDO 3.3.0 release a success <gregboone> 3.3 was included in MapGuide 2.0 and looks to be fairly stable and healthy <jasonbirch> Agreed. Pretty brave of those MG guys to release with RC FDO ;) <gregboone> True <orest> Extra QA! <jasonbirch> lol <gregboone> Note that I created a 3.3.0 branch for that release. It is pretty much a dead end branch at this point <gregboone> It is meant to support MapGuide 2.0 only <gregboone> I also created a 3.3.1 point release branch <jasonbirch> New features in 3.3.1? <gregboone> At this moment, the only known customer of this branch will be Autodesk Map and MapGuide <gregboone> This branch will only contain high priority fixes for issues found in 3.3.0 <jasonbirch> I'd like to convince Tom to do a 2.0.1 of MGOS too, mostly for Fusion improvements. But I saw a couple SDF fixes that looked interesting. <FrankW> Is 3.3.1 a suitable place to fix build quirks too (such as the #273 64bit ticket)? <gregboone> I felt a branch was necessary was necessary for 3.3.1 so that continued development could occur on the trunk <gregboone> FrankW: God question <gregboone> * good <FrankW> The fix is somewhat useful for general use of FDO but has limit value to mapguide which isn't 64bit anyways. <gregboone> Right. <gregboone> Unless a customer has indicated they want to use the 3.3.1 branch, it may make sense just to leave it in the trunk <osgeobot> fdofeed: PscMeeting200801 edited by warmerdam <http://trac.osgeo.org/fdo/wiki/PscMeeting200801> <FrankW> ok <jasonbirch> Would 3.3.2 (if it came along) be based on trunk or 3.3.1? <jasonbirch> Ie, are we going to 3.4 on trunk? <FrankW> But 3.3.1 is basically the stable release we would expect any non-mapguide FDO client to also use, right? <gregboone> I would say the trunk <gregboone> FrankW: Yes <FrankW> To be honest, I had expected there would be a 3.3 branch and 3.3.0/3.3.1 tags on that branch. <jasonbirch> That kinda makes sense to me too <gregboone> I am open to exploring that idea. <FrankW> That does seem to be implicit in the RFC 14 release process document, though not spelled out. <jasonbirch> Branches make more sense though if you're allowing ABI changes on point releases. <FrankW> Otherwise it is hard to ensure that point releases contain only bug fixes (if we make them branches off trunk each time) <FrankW> ! <gregboone> In the past we have not formally built off of tags, but of of branch versions <gregboone> True * FrankW hopes we will only entertain ABI changes in point releases under extreme conditions. <mloskot> tag is nothing different than a branch + remembered revision <jasonbirch> It's psychological mloskot <jasonbirch> :0 <FrankW> Right, but we think of branches as dynamic things, and tags as snapshots. It's a mental thing. IMHO <gregboone> So how can we move from the two brach strategy to one <gregboone> ? <gregboone> We could have to rename 3.3.0 -> 3.3 <mloskot> My point is that tags are useful and safer way of managing snapshots <jasonbirch> Or 3.3.x <gregboone> I see <mloskot> 3.3 <FrankW> Well 3.3.1 is effectively the 3.3 branch I think. So I would suggest renaming 3.3.0 as tags/3.3.0, and rename 3.3.1 branch as the 3.3 branch. <FrankW> If that isn't going to be too disruptive. <mloskot> FrankW: +1 <FrankW> Then "tag" 3.3.1 when we are ready to release it. <FrankW> This is also the practice on projects such as GDAL, and MapServer. <FrankW> (and GEOS) <gregboone> I will give a conditional +1. Let me investigate and get back to the PSC. <gregboone> I want to make sure our build processes can handle this easilty <FrankW> ok <gregboone> Orest: any objections? <orest> No objections, but check the build process as you said. <gregboone> ok <gregboone> Let's move to SQLServer <gregboone> I have posted a beta release for 3.3 and 3.2 <orest> Have you heard if anyone has tried the 3.2 build? <gregboone> No. I tried it in Map, but that is all I know of <jasonbirch> Oh, I dodn't realize there was a 3.2 build... <gregboone> There was an announcement <gregboone> Things are looking ok at this time. We know of a few issues but nothing too serious <orest> It's there in case someone wanted to try it with 3.2-based clients such as MG 2008. <jasonbirch> I can't bring up the minutes right now. SVN/Trac aren't playing nice for me. <orest> I'm having problems getting to fdo.osgeo.org right now. * FrankW is investigating... <gregboone> We are still working towards a full SQLServer release later this year in conjunction with the Microsoft launch <jasonbirch> Anyway... <jasonbirch> I've played some with the SQL Server provider. <jasonbirch> It's generally pretty good. <jasonbirch> As long as you don't have invalid data. <jasonbirch> :) <gregboone> :) <gregboone> orest: can you provide an update? <orest> Yes, I'm kind of worried about invalid data. <jasonbirch> Currently all it takes is one rogue Map user to mess up my MapGuide display :) <orest> We fixed some issues with SRID handling on query. There was also supposed to be a fix for handling that correctly on insert - I think it was dropped. <gregboone> orest: are we on schedule according to the RFC? <orest> Invalid data, which can be stored and is flagged as such in the server, causes an exception from SQL if you try to use it in a filter. <jasonbirch> And MapGuide always filters :) <orest> Yes, it always filters. Current work around is to use the MakeValid function on SQL to set the data as valid. <orest> I've asked exactly what that function does to your data, but haven't heard back yet. <orest> I think we're on track based on the phases described in the RFC. Next step is apply schema support for existing schema, and figure out processing of invalid data. <jasonbirch> I haven't tried setting up a view of IsValid data, and seeing whether it respects spatial indices yet. <orest> My guess is that it would not, but worth a try. <gregboone> Great. There has been a lot of expectation generated in the community <gregboone> It looks like this provider will be heavily used <orest> I've found SQL 2008 fairly stable considering that the spatial support is a version 1. <gregboone> How about the PostGIS provider? Has there been any movement in that area? I know an outside company was looking to invest resources <jasonbirch> Haven't heard from Bruno recently... <gregboone> They have not been vocal lately |<--mloskot has left freenode ("Leaving") <FrankW> I don't think it is worth holding back on 3.3.1 for those improvements if that is the question. <orest> You scared off mloskot. --> |mloskot (n=mloskot@osgeo/member/mloskot) has joined #FDO <FrankW> :-) <FrankW> trac is back, btw. <gregboone> Autodesk has really suspended efforts on PostGIS in expectation that Bruno would run with the PostGIS changes <jasonbirch> No, these are post 3.3.1 provider-specific releases <jasonbirch> Time to ping Bruno I guess. I can do that... <gregboone> That would be great <gregboone> I still have to release a document outlining the findings we made in our experience using the provider <orest> Bruno? <gregboone> we as in Autodesk <mloskot> gregboone: which one, there seems to be two providers in use <mloskot> first based on Generic RDBMS <mloskot> and second based on King Oracle approach <gregboone> The only PostGIS provider code base being maintained in the Providers/PostGIS code base <mloskot> ah, ok <mloskot> I'm asking because near Sept someone from Autodesk announced that the GRDBMS-based provider runs too <gregboone> Well, it does run, based on on initial work that was completed <mloskot> right <gregboone> But that code does not exist in OpenSource <mloskot> right, it lives in old SVN, my private branch <mloskot> anyway, seems it's a closed subject <gregboone> Ok. Let's ping Bruno Scott and see what is on the go <jasonbirch> will do. <gregboone> Concerning RFC 14. What is the status of this RFC? <FrankW> RFC 14 - the release process? <gregboone> I think it needs additional work? <gregboone> Sorry RFC 15 <gregboone> I got my RFC's mixed up <orest> RFC 15? I just sent an email today to Maksim to see if he's done anything recently on this RFC. He hasn't changed the doc yet based on email thread on fdo-internals. <jasonbirch> Yes, I think it's something that is sorely needed, but the RFC needs to be updated with feedback. <gregboone> OK. Let's have Maksim update the RFC and we can re-evaluate <orest> I think the concept is good. We just need to get the spec right. What do others think? <gregboone> I agree <gregboone> On to RFC 14? The FDO Release process. I have heard back from Jason, but not others. What do people think? <mloskot> The release process and versioning scheme works for me. <FrankW> I'm generally supportive but have not reviewed it in the detail I ought to. <mloskot> Are we going to rotate release managers every 6 months? <FrankW> Given our relationship to the MapGuide project is a six month fixed release cycle really the best choice? <gregboone> mloskot: probably not <jasonbirch> Heh. <gregboone> FrankW: 6 months in an idea <gregboone> I am not sure of the practicality <jasonbirch> I think it's probably realistic given ADSK's availability cycle though. :) <gregboone> It would be easier to determine an appropriate cycle if we had other customers pushing for functionality/fixes <mloskot> Do we consider that a release manager can be selected from the community? <FrankW> I presume the "heavy weight" process relates to major releases (3.3, 3.4) not the point releases, right? <FrankW> A release manager *could* come from outside ADSK, but I doubt that would be the case with the possible exception of bug fix releases. <mloskot> The list of tasks seems to be pretty big, so it will require significant amount of time, so perhaps only full time manager is an option. <gregboone> mloskot: Yes. But in all practicality, someone from Autodesk will have to assume the role until we gets the build process moved off of Autodesk servers <mloskot> That clarifies my concerns. <mloskot> OK <jasonbirch> And the hypothetical QA/website teams form :) <gregboone> LOL <gregboone> That is true <FrankW> I assume that there is a formal QA process inside ADSK, and that outside QA is mostly informal use of the betas, and such. Is that right? <gregboone> Correct <FrankW> There is no reason outside folks can't run the regression tests in different environments. <FrankW> I'd like to see more of that in the future. <FrankW> (the test suites in the source tree) <jasonbirch> And BuildBot... * mloskot supports this idea as an important factor for building the FDO community <gregboone> BuildBot support would be nice <gregboone> We need someone to make that happen <orest> Community input on test suites would be good. <mloskot> I did it some time ago <mloskot> As you can see, FDO is configured but offline - http://buildbot.osgeo.org/ <FrankW> I think mloskot can refresh the buildbot support when his availability improves. :-) <gregboone> mloskot: Why can't this be started? <FrankW> We do have the disk space on the buildbot server now which was an issue for a while. <mloskot> I turned it off because of a few problems: <mloskot> - lack of disk space we experienced <mloskot> - problems with SVN robustness, we experienced a few months ago <gregboone> We also would need the build to package the tar files appropriately <mloskot> - not much feedback from the team about need of Buildbot (I announced on the list but nothing happened) <FrankW> buildbot is not for preparing packaged releases - it is for a build and smoke test. <mloskot> etc. <gregboone> Ok <mloskot> Completing Frank's words, packages can be prepared with simple scripts, as it's done for GDAL <gregboone> Well, I am in favor of turning it on. Let's see what happens <mloskot> gregboone: OK, I will do it during the weekend <gregboone> mloskot: that process should be automated <mloskot> We are good regarding the disk space now <FrankW> As for packaged releases, I'm interested in having FDO in in OSGeo4W at some point. I believe some folks at DMSolutions will attempt this from the MapGuide 2.0 binaries. <mloskot> FrankW: am I correct? <FrankW> mloskot: yes <mloskot> gregboone: it is automated for GDAL <jasonbirch> mloskot: are you hitting osgeo directly, or the mirrored svn? <mloskot> gregboone: http://download.osgeo.org/gdal/daily/ <gregboone> mloskot: Are all thirdparty components/providers building as part of buildbot? <mloskot> jasonbirch: directly <mloskot> gregboone: yes, and that's another issue, it takes long time to build <jasonbirch> You're probably the one crashing the server then ;) (kidding) <mloskot> 1-1.5 hr <gregboone> mloskot: it does <mloskot> That's one of the reasons I had to turn it off <FrankW> Yes, it is a very demanding library from a buildtime point of view. <mloskot> Perhaps we can use incremental builds for now <FrankW> We wouldn't want the auto-build-on-svn-commit turned on. <mloskot> and see how it operates for us <gregboone> Well, can't we have Thirdparty built only on demand? <mloskot> gregboone: building with BB does not differ from how you build FDO on your computer <mloskot> So, if there is an option/switch to achieve that, then BB can use it as well <mloskot> I mean , 3rd party on demand <gregboone> mloskot: let's discuss offline and see what can be done <mloskot> [back to reasons} there was yet another one, we had huge number of WWW files in the repo, so it took ages to do svn update, so I turned the BB off <mloskot> gregboone: OK <gregboone> If so, incremental auto-build-on-svn-commit should be ok <mloskot> right <gregboone> Great! This is good news <gregboone> We would need builds for trunk and the 3.3 branch <mloskot> I think we can use the same scheme as GDAL: trunk + current stable branch <mloskot> ok, I'm taking this task <gregboone> What about Windows and Linux? <gregboone> Is there a build for each? If so, which vrsions? <FrankW> Given the demanding nature of an FDO build, I would suggest we get one buildbot slave working smoothly before adding too many cases. <gregboone> FrankW: Which OS would be supported first? <FrankW> In my (indirect) experience keeping buildbot operational does require some effort, so we should avoid multiplying this too much. <mloskot> gregboone: We host only Linux build machines on osgeo infrastructure <FrankW> I would suggest linux is easiest. <mloskot> but it's possible to connect external machines <mloskot> BB is a distributed beast <gregboone> Which version of Linux do we use? <mloskot> AFAIR, Fedora Core 4 <FrankW> The telascience systems are mostly fedora core 4. <gregboone> Ok. <mloskot> FrankW: you mean one slave in general or one slave on osgeo machines? <FrankW> I'm suggesting one slave in general for now, to see if it is useful, etc. before investing too much effort. <orest> I have to leave, I have another meeting starting now. <FrankW> (mloskot is also more busy than he might be willing to admit!) <mloskot> FrankW: ok <mloskot> FrankW: I agree, I usually take too much tasks than I can handle :-) <gregboone> We need to get other resources (Such as myself) involved so that we have distributed knowlwdge <FrankW> gregboone: you might want to review: http://wiki.osgeo.org/wiki/BuildBot_Configuration <mloskot> I'm staying as "disappeared" from bigger hacking for next 1-1.5 months, but the Buildbot maintenance hasn't been overwhelming for me, so I'll keep my eye on it. <jasonbirch> Bye orest <FrankW> If we eventually have an OSGeo/telascience windows VM perhaps you could work with mloskot to setup an fdo buildbot slave on it. <mloskot> gregboone: Here is description of GDAL BB instances: http://trac.osgeo.org/gdal/wiki/Buildbot <mloskot> gregboone: I think we can clone it in some way <mloskot> telascience-quick and telascience-stable <mloskot> FrankW: there are 2 or 3 Builbot slaves installed on VM under Windows <mloskot> I just turned them off, because of limited resources <gregboone> Ok. Maybe we can continue this discussion offline. <mloskot> OK <mloskot> What's next? <gregboone> Moving on.... So where is FDO headed? What do people think we need to do for the next major release? <gregboone> Too bad orest had to leave <jasonbirch> That's OK, we can make major decisions without him :) <gregboone> :) <mloskot> Trac is down for me <mloskot> Anyway, I'd like to continue stripping Boost <FrankW> trac is responding well for me right now. <gregboone> We have some futures documents posted <mloskot> #189 and #205 <gregboone> mloskot: sure <mloskot> I submitted small improvements, but the minimal distribution is not ready yet <gregboone> However, we have not had much feedback <gregboone> We need to get feedback from MapGuide folks as well as Harris <gregboone> Also, 1Spatial and the FME guys. <mloskot> gregboone: incorporating idea explained in the #205 should speed up compilation significantly <gregboone> mloskot: ok. This can be done in the trunk <gregboone> We can port to 3.3 once the branches are sorted out <mloskot> ok <mloskot> What's next topic on the board? <gregboone> We are still discussing futures <gregboone> The next release of FDO <gregboone> Well, maybe this topic is best suited for another meeting :) <mloskot> I don't mind <jasonbirch> What is missing? <jasonbirch> I thought FDO was perfect? :) <gregboone> haha <mloskot> I also think the building community topic is a big one and probably best if we are all here <gregboone> Last year there was discussion around a Client layer <jasonbirch> I'd love to get some involvement from vertical app builders like Munsys to see what they would want. <gregboone> That has not progressed * mloskot is very happy jasonbirch loves PostGIS provider :-) <jasonbirch> Doh... <gregboone> jasonbirch: Agreed <jasonbirch> I meant the API :) <jasonbirch> Client layer, especially for projection and leveling of providers, would make me very happy. <jasonbirch> Right now, amount of work just to see what providers support in client apps is painful. <gregboone> I will be honest here and say we need non-Autodesk development resources to be heavily involved with such an effort <mloskot> Have we considered participation of Google Summer of Code 2008? <mloskot> I think projects like command line utilities would be very nice for GSoC <mloskot> for students <FrankW> yes, that would be a plausible sort of project. <mloskot> not very complex, but with nice and observable results <jasonbirch> Wish Haris was here... <FrankW> I'm not sure that FDO has much visibility at the academic level though. <FrankW> It may be hard to find students to get involved. <mloskot> Perhaps Autodesk University could help in finding students? <FrankW> But it isn't hard to post a few ideas. <gregboone> I am open to hearing ideas and seeing where that leads us <mloskot> I've seen Autodesk internships on the Web, may be some students could be asked/delegated to GSoC and FDO Open Source <mloskot> These are very loose ideas <mloskot> sorry if I'm discussing in the area being "not my business" <gregboone> lol <mloskot> :-) <mloskot> As I do for GDAL and GEOS, I will spread the FDO GSoC on forums of Polish universities, etc. <gregboone> OK. I guess this all ties into getting new developers interested in FDO <mloskot> but we need projects proposals <gregboone> .. and growing the community <gregboone> We need to grow our base and spread the word <jasonbirch> Could be pimped as command-line tool to load to/from SQL Server Spatial... <gregboone> Insn't that fdo2fdo? <jasonbirch> Only on Windows. <FrankW> I do worry about duplicating fdo2fdo, and "making fdo2fdo more usable/buildable" isn't going to be a fun SoC project. <mloskot> The community subject is big and probably requires deeper/longer discussion. What about doing it on the fdo-internals and then make a meeting to discuss outcome? <gregboone> mloskot: Ok <mloskot> Plus, fdo2fdo is an existing application <jasonbirch> I don't know how GDAL has built such a large community. <gregboone> Well, fdo3fdo needs to move intro the trunk in order to be maintained <FrankW> approachability, fill a critical gap, and 10 years... <jasonbirch> Probably because it's usable without API too. <mloskot> 2 months is too short to taking up an existing software, explore it and add new functionality, especially for students <mloskot> IMHO GSoC project is better to be simple, concise and finite <FrankW> agreed <gregboone> Yes <gregboone> Ok all... maybe we should wrap this up? We can continue these discussions on fdo-internals? <mloskot> I agree <jasonbirch> Yes. <gregboone> Thanks to all who attended <jasonbirch> Next year, perhaps we can start thinking about GSoC earlier... <gregboone> I will post the meeting notes <gregboone> jasonbirch: Agreed <mloskot> We have 2 weeks to think of project proposals <mloskot> I mean, there is not much to prepare to attend GSoC. Usually, students should bring their ideas <mloskot> So, the most important is to reach mass of students <mloskot> with announcement <mloskot> http://code.google.com/soc/2008/faqs.html#0.1_timeline <jasonbirch> The OSGeo submission has been made, but we can still add ideas/mentors to our list. <mloskot> ah, right <gregboone> Just an FYI... Something I heard in the grapevine... We will have to consider what is needed in FDO in order to support VS2008 <gregboone> Whatever changes are required will only be made in the trunk <gregboone> Maybe an RFC will be in order here <jasonbirch> I haven't looked at the existing support... <jasonbirch> You mean for building FDO, or using the API? <mloskot> I'd not expect any significant fixes required <gregboone> Build support mostly. <gregboone> We may need a couple of configurations <gregboone> Also, do we release a version for 2005 and 2008? <mloskot> gregboone: you mean binaries? <gregboone> mloskot: Yes. If that is required <mloskot> In both, manifests are available <mloskot> so, I'd assume bins are compatible