| | 28 | |
| | 29 | == Transcript == |
| | 30 | |
| | 31 | {{{ |
| | 32 | <gregboone>Hi All. The meeting will start shortly. I want to give others a few moments to join |
| | 33 | <osgeobot> fdofeed: PscMeeting200801 edited by mloskot <http://trac.osgeo.org/fdo/wiki/PscMeeting200801> |
| | 34 | <gregboone>Well... Let's start and others can join as they see fit |
| | 35 | <orest>We're still missing three people. |
| | 36 | <gregboone>Yes... I don't know if they will join today |
| | 37 | <gregboone>Haris looks doubtful |
| | 38 | <orest>Yes, I saw his email. |
| | 39 | <gregboone>Jason should be here. I will ping him. |
| | 40 | -->|jasonbirch (n=jasonbir@199.175.138.1) has joined #FDO |
| | 41 | <gregboone>I also pinged Bob |
| | 42 | <gregboone>Hi Jason |
| | 43 | <jasonbirch>allo |
| | 44 | <jasonbirch>sorry, was distracted. I'm still running mg 0.91 on my public server and it's getting hammered because of recent press. |
| | 45 | <gregboone>No worries. We are just starting. |
| | 46 | <gregboone>I will start off and congratulate all those who helped make the FDO 3.3.0 release a success |
| | 47 | <gregboone>3.3 was included in MapGuide 2.0 and looks to be fairly stable and healthy |
| | 48 | <jasonbirch>Agreed. Pretty brave of those MG guys to release with RC FDO ;) |
| | 49 | <gregboone>True |
| | 50 | <orest>Extra QA! |
| | 51 | <jasonbirch>lol |
| | 52 | <gregboone>Note that I created a 3.3.0 branch for that release. It is pretty much a dead end branch at this point |
| | 53 | <gregboone>It is meant to support MapGuide 2.0 only |
| | 54 | <gregboone>I also created a 3.3.1 point release branch |
| | 55 | <jasonbirch>New features in 3.3.1? |
| | 56 | <gregboone>At this moment, the only known customer of this branch will be Autodesk Map and MapGuide |
| | 57 | <gregboone>This branch will only contain high priority fixes for issues found in 3.3.0 |
| | 58 | <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. |
| | 59 | <FrankW>Is 3.3.1 a suitable place to fix build quirks too (such as the #273 64bit ticket)? |
| | 60 | <gregboone>I felt a branch was necessary was necessary for 3.3.1 so that continued development could occur on the trunk |
| | 61 | <gregboone>FrankW: God question |
| | 62 | <gregboone>* good |
| | 63 | <FrankW>The fix is somewhat useful for general use of FDO but has limit value to mapguide which isn't 64bit anyways. |
| | 64 | <gregboone>Right. |
| | 65 | <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 |
| | 66 | <osgeobot>fdofeed: PscMeeting200801 edited by warmerdam <http://trac.osgeo.org/fdo/wiki/PscMeeting200801> |
| | 67 | <FrankW>ok |
| | 68 | <jasonbirch>Would 3.3.2 (if it came along) be based on trunk or 3.3.1? |
| | 69 | <jasonbirch>Ie, are we going to 3.4 on trunk? |
| | 70 | <FrankW>But 3.3.1 is basically the stable release we would expect any non-mapguide FDO client to also use, right? |
| | 71 | <gregboone>I would say the trunk |
| | 72 | <gregboone>FrankW: Yes |
| | 73 | <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. |
| | 74 | <jasonbirch>That kinda makes sense to me too |
| | 75 | <gregboone>I am open to exploring that idea. |
| | 76 | <FrankW>That does seem to be implicit in the RFC 14 release process document, though not spelled out. |
| | 77 | <jasonbirch>Branches make more sense though if you're allowing ABI changes on point releases. |
| | 78 | <FrankW>Otherwise it is hard to ensure that point releases contain only bug fixes (if we make them branches off trunk each time) |
| | 79 | <FrankW>! |
| | 80 | <gregboone>In the past we have not formally built off of tags, but of of branch versions |
| | 81 | <gregboone>True |
| | 82 | * FrankW hopes we will only entertain ABI changes in point releases under extreme conditions. |
| | 83 | <mloskot>tag is nothing different than a branch + remembered revision |
| | 84 | <jasonbirch>It's psychological mloskot |
| | 85 | <jasonbirch>:0 |
| | 86 | <FrankW>Right, but we think of branches as dynamic things, and tags as snapshots. It's a mental thing. IMHO |
| | 87 | <gregboone>So how can we move from the two brach strategy to one |
| | 88 | <gregboone>? |
| | 89 | <gregboone>We could have to rename 3.3.0 -> 3.3 |
| | 90 | <mloskot>My point is that tags are useful and safer way of managing snapshots |
| | 91 | <jasonbirch>Or 3.3.x |
| | 92 | <gregboone>I see |
| | 93 | <mloskot>3.3 |
| | 94 | <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. |
| | 95 | <FrankW>If that isn't going to be too disruptive. |
| | 96 | <mloskot>FrankW: +1 |
| | 97 | <FrankW>Then "tag" 3.3.1 when we are ready to release it. |
| | 98 | <FrankW>This is also the practice on projects such as GDAL, and MapServer. |
| | 99 | <FrankW>(and GEOS) |
| | 100 | <gregboone>I will give a conditional +1. Let me investigate and get back to the PSC. |
| | 101 | <gregboone>I want to make sure our build processes can handle this easilty |
| | 102 | <FrankW>ok |
| | 103 | <gregboone>Orest: any objections? |
| | 104 | <orest>No objections, but check the build process as you said. |
| | 105 | <gregboone>ok |
| | 106 | <gregboone>Let's move to SQLServer |
| | 107 | <gregboone>I have posted a beta release for 3.3 and 3.2 |
| | 108 | <orest>Have you heard if anyone has tried the 3.2 build? |
| | 109 | <gregboone>No. I tried it in Map, but that is all I know of |
| | 110 | <jasonbirch>Oh, I dodn't realize there was a 3.2 build... |
| | 111 | <gregboone>There was an announcement |
| | 112 | <gregboone>Things are looking ok at this time. We know of a few issues but nothing too serious |
| | 113 | <orest>It's there in case someone wanted to try it with 3.2-based clients such as MG 2008. |
| | 114 | <jasonbirch>I can't bring up the minutes right now. SVN/Trac aren't playing nice for me. |
| | 115 | <orest>I'm having problems getting to fdo.osgeo.org right now. |
| | 116 | * FrankW is investigating... |
| | 117 | <gregboone>We are still working towards a full SQLServer release later this year in conjunction with the Microsoft launch |
| | 118 | <jasonbirch>Anyway... |
| | 119 | <jasonbirch>I've played some with the SQL Server provider. |
| | 120 | <jasonbirch>It's generally pretty good. |
| | 121 | <jasonbirch>As long as you don't have invalid data. |
| | 122 | <jasonbirch>:) |
| | 123 | <gregboone>:) |
| | 124 | <gregboone>orest: can you provide an update? |
| | 125 | <orest>Yes, I'm kind of worried about invalid data. |
| | 126 | <jasonbirch>Currently all it takes is one rogue Map user to mess up my MapGuide display :) |
| | 127 | <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. |
| | 128 | <gregboone>orest: are we on schedule according to the RFC? |
| | 129 | <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. |
| | 130 | <jasonbirch>And MapGuide always filters :) |
| | 131 | <orest>Yes, it always filters. Current work around is to use the MakeValid function on SQL to set the data as valid. |
| | 132 | <orest>I've asked exactly what that function does to your data, but haven't heard back yet. |
| | 133 | <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. |
| | 134 | <jasonbirch>I haven't tried setting up a view of IsValid data, and seeing whether it respects spatial indices yet. |
| | 135 | <orest>My guess is that it would not, but worth a try. |
| | 136 | <gregboone>Great. There has been a lot of expectation generated in the community |
| | 137 | <gregboone>It looks like this provider will be heavily used |
| | 138 | <orest>I've found SQL 2008 fairly stable considering that the spatial support is a version 1. |
| | 139 | <gregboone>How about the PostGIS provider? Has there been any movement in that area? I know an outside company was looking to invest resources |
| | 140 | <jasonbirch>Haven't heard from Bruno recently... |
| | 141 | <gregboone>They have not been vocal lately |
| | 142 | |<--mloskot has left freenode ("Leaving") |
| | 143 | <FrankW>I don't think it is worth holding back on 3.3.1 for those improvements if that is the question. |
| | 144 | <orest>You scared off mloskot. |
| | 145 | -->|mloskot (n=mloskot@osgeo/member/mloskot) has joined #FDO |
| | 146 | <FrankW>:-) |
| | 147 | <FrankW>trac is back, btw. |
| | 148 | <gregboone>Autodesk has really suspended efforts on PostGIS in expectation that Bruno would run with the PostGIS changes |
| | 149 | <jasonbirch>No, these are post 3.3.1 provider-specific releases |
| | 150 | <jasonbirch>Time to ping Bruno I guess. I can do that... |
| | 151 | <gregboone>That would be great |
| | 152 | <gregboone>I still have to release a document outlining the findings we made in our experience using the provider |
| | 153 | <orest>Bruno? |
| | 154 | <gregboone>we as in Autodesk |
| | 155 | <mloskot>gregboone: which one, there seems to be two providers in use |
| | 156 | <mloskot>first based on Generic RDBMS |
| | 157 | <mloskot>and second based on King Oracle approach |
| | 158 | <gregboone>The only PostGIS provider code base being maintained in the Providers/PostGIS code base |
| | 159 | <mloskot>ah, ok |
| | 160 | <mloskot>I'm asking because near Sept someone from Autodesk announced that the GRDBMS-based provider runs too |
| | 161 | <gregboone>Well, it does run, based on on initial work that was completed |
| | 162 | <mloskot>right |
| | 163 | <gregboone>But that code does not exist in OpenSource |
| | 164 | <mloskot>right, it lives in old SVN, my private branch |
| | 165 | <mloskot>anyway, seems it's a closed subject |
| | 166 | <gregboone>Ok. Let's ping Bruno Scott and see what is on the go |
| | 167 | <jasonbirch>will do. |
| | 168 | <gregboone>Concerning RFC 14. What is the status of this RFC? |
| | 169 | <FrankW>RFC 14 - the release process? |
| | 170 | <gregboone>I think it needs additional work? |
| | 171 | <gregboone>Sorry RFC 15 |
| | 172 | <gregboone>I got my RFC's mixed up |
| | 173 | <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. |
| | 174 | <jasonbirch>Yes, I think it's something that is sorely needed, but the RFC needs to be updated with feedback. |
| | 175 | <gregboone>OK. Let's have Maksim update the RFC and we can re-evaluate |
| | 176 | <orest>I think the concept is good. We just need to get the spec right. What do others think? |
| | 177 | <gregboone>I agree |
| | 178 | <gregboone>On to RFC 14? The FDO Release process. I have heard back from Jason, but not others. What do people think? |
| | 179 | <mloskot>The release process and versioning scheme works for me. |
| | 180 | <FrankW>I'm generally supportive but have not reviewed it in the detail I ought to. |
| | 181 | <mloskot>Are we going to rotate release managers every 6 months? |
| | 182 | <FrankW>Given our relationship to the MapGuide project is a six month fixed release cycle really the best choice? |
| | 183 | <gregboone>mloskot: probably not |
| | 184 | <jasonbirch>Heh. |
| | 185 | <gregboone>FrankW: 6 months in an idea |
| | 186 | <gregboone>I am not sure of the practicality |
| | 187 | <jasonbirch>I think it's probably realistic given ADSK's availability cycle though. :) |
| | 188 | <gregboone>It would be easier to determine an appropriate cycle if we had other customers pushing for functionality/fixes |
| | 189 | <mloskot>Do we consider that a release manager can be selected from the community? |
| | 190 | <FrankW>I presume the "heavy weight" process relates to major releases (3.3, 3.4) not the point releases, right? |
| | 191 | <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. |
| | 192 | <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. |
| | 193 | <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 |
| | 194 | <mloskot>That clarifies my concerns. |
| | 195 | <mloskot>OK |
| | 196 | <jasonbirch> |
| | 197 | And the hypothetical QA/website teams form :) |
| | 198 | <gregboone>LOL |
| | 199 | <gregboone>That is true |
| | 200 | <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? |
| | 201 | <gregboone>Correct |
| | 202 | <FrankW>There is no reason outside folks can't run the regression tests in different environments. |
| | 203 | <FrankW>I'd like to see more of that in the future. |
| | 204 | <FrankW>(the test suites in the source tree) |
| | 205 | <jasonbirch>And BuildBot... |
| | 206 | * mloskot supports this idea as an important factor for building the FDO community |
| | 207 | <gregboone>BuildBot support would be nice |
| | 208 | <gregboone>We need someone to make that happen |
| | 209 | <orest>Community input on test suites would be good. |
| | 210 | <mloskot>I did it some time ago |
| | 211 | <mloskot>As you can see, FDO is configured but offline - http://buildbot.osgeo.org/ |
| | 212 | <FrankW>I think mloskot can refresh the buildbot support when his availability improves. :-) |
| | 213 | <gregboone>mloskot: Why can't this be started? |
| | 214 | <FrankW>We do have the disk space on the buildbot server now which was an issue for a while. |
| | 215 | <mloskot>I turned it off because of a few problems: |
| | 216 | <mloskot>- lack of disk space we experienced |
| | 217 | <mloskot>- problems with SVN robustness, we experienced a few months ago |
| | 218 | <gregboone>We also would need the build to package the tar files appropriately |
| | 219 | <mloskot>- not much feedback from the team about need of Buildbot (I announced on the list but nothing happened) |
| | 220 | <FrankW>buildbot is not for preparing packaged releases - it is for a build and smoke test. |
| | 221 | <mloskot>etc. |
| | 222 | <gregboone>Ok |
| | 223 | <mloskot>Completing Frank's words, packages can be prepared with simple scripts, as it's done for GDAL |
| | 224 | <gregboone>Well, I am in favor of turning it on. Let's see what happens |
| | 225 | <mloskot>gregboone: OK, I will do it during the weekend |
| | 226 | <gregboone>mloskot: that process should be automated |
| | 227 | <mloskot>We are good regarding the disk space now |
| | 228 | <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. |
| | 229 | <mloskot>FrankW: am I correct? |
| | 230 | <FrankW>mloskot: yes |
| | 231 | <mloskot>gregboone: it is automated for GDAL |
| | 232 | <jasonbirch>mloskot: are you hitting osgeo directly, or the mirrored svn? |
| | 233 | <mloskot>gregboone: http://download.osgeo.org/gdal/daily/ |
| | 234 | <gregboone>mloskot: Are all thirdparty components/providers building as part of buildbot? |
| | 235 | <mloskot>jasonbirch: directly |
| | 236 | <mloskot>gregboone: yes, and that's another issue, it takes long time to build |
| | 237 | <jasonbirch>You're probably the one crashing the server then ;) (kidding) |
| | 238 | <mloskot>1-1.5 hr |
| | 239 | <gregboone>mloskot: it does |
| | 240 | <mloskot>That's one of the reasons I had to turn it off |
| | 241 | <FrankW>Yes, it is a very demanding library from a buildtime point of view. |
| | 242 | <mloskot>Perhaps we can use incremental builds for now |
| | 243 | <FrankW>We wouldn't want the auto-build-on-svn-commit turned on. |
| | 244 | <mloskot>and see how it operates for us |
| | 245 | <gregboone>Well, can't we have Thirdparty built only on demand? |
| | 246 | <mloskot>gregboone: building with BB does not differ from how you build FDO on your computer |
| | 247 | <mloskot>So, if there is an option/switch to achieve that, then BB can use it as well |
| | 248 | <mloskot>I mean , 3rd party on demand |
| | 249 | <gregboone>mloskot: let's discuss offline and see what can be done |
| | 250 | <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 |
| | 251 | <mloskot>gregboone: OK |
| | 252 | <gregboone>If so, incremental auto-build-on-svn-commit should be ok |
| | 253 | <mloskot>right |
| | 254 | <gregboone>Great! This is good news |
| | 255 | <gregboone>We would need builds for trunk and the 3.3 branch |
| | 256 | <mloskot>I think we can use the same scheme as GDAL: trunk + current stable branch |
| | 257 | <mloskot>ok, I'm taking this task |
| | 258 | <gregboone>What about Windows and Linux? |
| | 259 | <gregboone>Is there a build for each? If so, which vrsions? |
| | 260 | <FrankW>Given the demanding nature of an FDO build, I would suggest we get one buildbot slave working smoothly before adding too many cases. |
| | 261 | <gregboone>FrankW: Which OS would be supported first? |
| | 262 | <FrankW>In my (indirect) experience keeping buildbot operational does require some effort, so we should avoid multiplying this too much. |
| | 263 | <mloskot>gregboone: We host only Linux build machines on osgeo infrastructure |
| | 264 | <FrankW>I would suggest linux is easiest. |
| | 265 | <mloskot>but it's possible to connect external machines |
| | 266 | <mloskot>BB is a distributed beast |
| | 267 | <gregboone>Which version of Linux do we use? |
| | 268 | <mloskot>AFAIR, Fedora Core 4 |
| | 269 | <FrankW>The telascience systems are mostly fedora core 4. |
| | 270 | <gregboone>Ok. |
| | 271 | <mloskot>FrankW: you mean one slave in general or one slave on osgeo machines? |
| | 272 | <FrankW>I'm suggesting one slave in general for now, to see if it is useful, etc. before investing too much effort. |
| | 273 | <orest>I have to leave, I have another meeting starting now. |
| | 274 | <FrankW>(mloskot is also more busy than he might be willing to admit!) |
| | 275 | <mloskot>FrankW: ok |
| | 276 | <mloskot>FrankW: I agree, I usually take too much tasks than I can handle :-) |
| | 277 | <gregboone>We need to get other resources (Such as myself) involved so that we have distributed knowlwdge |
| | 278 | <FrankW>gregboone: you might want to review: http://wiki.osgeo.org/wiki/BuildBot_Configuration |
| | 279 | <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. |
| | 280 | <jasonbirch>Bye orest |
| | 281 | <FrankW>If we eventually have an OSGeo/telascience windows VM perhaps you could work with mloskot to setup an fdo buildbot slave on it. |
| | 282 | <mloskot>gregboone: Here is description of GDAL BB instances: http://trac.osgeo.org/gdal/wiki/Buildbot |
| | 283 | <mloskot>gregboone: I think we can clone it in some way |
| | 284 | <mloskot>telascience-quick and telascience-stable |
| | 285 | <mloskot>FrankW: there are 2 or 3 Builbot slaves installed on VM under Windows |
| | 286 | <mloskot>I just turned them off, because of limited resources |
| | 287 | <gregboone>Ok. Maybe we can continue this discussion offline. |
| | 288 | <mloskot>OK |
| | 289 | <mloskot>What's next? |
| | 290 | <gregboone>Moving on.... So where is FDO headed? What do people think we need to do for the next major release? |
| | 291 | <gregboone>Too bad orest had to leave |
| | 292 | <jasonbirch>That's OK, we can make major decisions without him :) |
| | 293 | <gregboone>:) |
| | 294 | <mloskot>Trac is down for me |
| | 295 | <mloskot>Anyway, I'd like to continue stripping Boost |
| | 296 | <FrankW>trac is responding well for me right now. |
| | 297 | <gregboone>We have some futures documents posted |
| | 298 | <mloskot>#189 and #205 |
| | 299 | <gregboone>mloskot: sure |
| | 300 | <mloskot>I submitted small improvements, but the minimal distribution is not ready yet |
| | 301 | <gregboone>However, we have not had much feedback |
| | 302 | <gregboone>We need to get feedback from MapGuide folks as well as Harris |
| | 303 | <gregboone>Also, 1Spatial and the FME guys. |
| | 304 | <mloskot>gregboone: incorporating idea explained in the #205 should speed up compilation significantly |
| | 305 | <gregboone>mloskot: ok. This can be done in the trunk |
| | 306 | <gregboone>We can port to 3.3 once the branches are sorted out |
| | 307 | <mloskot>ok |
| | 308 | <mloskot>What's next topic on the board? |
| | 309 | <gregboone>We are still discussing futures |
| | 310 | <gregboone>The next release of FDO |
| | 311 | <gregboone>Well, maybe this topic is best suited for another meeting :) |
| | 312 | <mloskot>I don't mind |
| | 313 | <jasonbirch>What is missing? |
| | 314 | <jasonbirch>I thought FDO was perfect? :) |
| | 315 | <gregboone>haha |
| | 316 | <mloskot>I also think the building community topic is a big one and probably best if we are all here |
| | 317 | <gregboone>Last year there was discussion around a Client layer |
| | 318 | <jasonbirch>I'd love to get some involvement from vertical app builders like Munsys to see what they would want. |
| | 319 | <gregboone>That has not progressed |
| | 320 | * mloskot is very happy jasonbirch loves PostGIS provider :-) |
| | 321 | <jasonbirch>Doh... |
| | 322 | <gregboone>jasonbirch: Agreed |
| | 323 | <jasonbirch>I meant the API :) |
| | 324 | <jasonbirch>Client layer, especially for projection and leveling of providers, would make me very happy. |
| | 325 | <jasonbirch>Right now, amount of work just to see what providers support in client apps is painful. |
| | 326 | <gregboone>I will be honest here and say we need non-Autodesk development resources to be heavily involved with such an effort |
| | 327 | <mloskot>Have we considered participation of Google Summer of Code 2008? |
| | 328 | <mloskot>I think projects like command line utilities would be very nice for GSoC |
| | 329 | <mloskot>for students |
| | 330 | <FrankW>yes, that would be a plausible sort of project. |
| | 331 | <mloskot>not very complex, but with nice and observable results |
| | 332 | <jasonbirch>Wish Haris was here... |
| | 333 | <FrankW>I'm not sure that FDO has much visibility at the academic level though. |
| | 334 | <FrankW>It may be hard to find students to get involved. |
| | 335 | <mloskot>Perhaps Autodesk University could help in finding students? |
| | 336 | <FrankW>But it isn't hard to post a few ideas. |
| | 337 | <gregboone>I am open to hearing ideas and seeing where that leads us |
| | 338 | <mloskot>I've seen Autodesk internships on the Web, may be some students could be asked/delegated to GSoC and FDO Open Source |
| | 339 | <mloskot>These are very loose ideas |
| | 340 | <mloskot>sorry if I'm discussing in the area being "not my business" |
| | 341 | <gregboone>lol |
| | 342 | <mloskot>:-) |
| | 343 | <mloskot>As I do for GDAL and GEOS, I will spread the FDO GSoC on forums of Polish universities, etc. |
| | 344 | <gregboone>OK. I guess this all ties into getting new developers interested in FDO |
| | 345 | <mloskot>but we need projects proposals |
| | 346 | <gregboone>.. and growing the community |
| | 347 | <gregboone>We need to grow our base and spread the word |
| | 348 | <jasonbirch>Could be pimped as command-line tool to load to/from SQL Server Spatial... |
| | 349 | <gregboone>Insn't that fdo2fdo? |
| | 350 | <jasonbirch>Only on Windows. |
| | 351 | <FrankW>I do worry about duplicating fdo2fdo, and "making fdo2fdo more usable/buildable" isn't going to be a fun SoC project. |
| | 352 | <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? |
| | 353 | <gregboone>mloskot: Ok |
| | 354 | <mloskot>Plus, fdo2fdo is an existing application |
| | 355 | <jasonbirch>I don't know how GDAL has built such a large community. |
| | 356 | <gregboone>Well, fdo3fdo needs to move intro the trunk in order to be maintained |
| | 357 | <FrankW>approachability, fill a critical gap, and 10 years... |
| | 358 | <jasonbirch>Probably because it's usable without API too. |
| | 359 | <mloskot>2 months is too short to taking up an existing software, explore it and add new functionality, especially for students |
| | 360 | <mloskot>IMHO GSoC project is better to be simple, concise and finite |
| | 361 | <FrankW>agreed |
| | 362 | <gregboone>Yes |
| | 363 | <gregboone>Ok all... maybe we should wrap this up? We can continue these discussions on fdo-internals? |
| | 364 | <mloskot>I agree |
| | 365 | <jasonbirch>Yes. |
| | 366 | <gregboone>Thanks to all who attended |
| | 367 | <jasonbirch>Next year, perhaps we can start thinking about GSoC earlier... |
| | 368 | <gregboone>I will post the meeting notes |
| | 369 | <gregboone>jasonbirch: Agreed |
| | 370 | <mloskot>We have 2 weeks to think of project proposals |
| | 371 | <mloskot>I mean, there is not much to prepare to attend GSoC. Usually, students should bring their ideas |
| | 372 | <mloskot>So, the most important is to reach mass of students |
| | 373 | <mloskot>with announcement |
| | 374 | <mloskot>http://code.google.com/soc/2008/faqs.html#0.1_timeline |
| | 375 | <jasonbirch>The OSGeo submission has been made, but we can still add ideas/mentors to our list. |
| | 376 | <mloskot>ah, right |
| | 377 | <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 |
| | 378 | <gregboone>Whatever changes are required will only be made in the trunk |
| | 379 | <gregboone>Maybe an RFC will be in order here |
| | 380 | <jasonbirch>I haven't looked at the existing support... |
| | 381 | <jasonbirch>You mean for building FDO, or using the API? |
| | 382 | <mloskot>I'd not expect any significant fixes required |
| | 383 | <gregboone>Build support mostly. |
| | 384 | <gregboone>We may need a couple of configurations |
| | 385 | <gregboone>Also, do we release a version for 2005 and 2008? |
| | 386 | <mloskot>gregboone: you mean binaries? |
| | 387 | <gregboone>mloskot: Yes. If that is required |
| | 388 | <mloskot>In both, manifests are available |
| | 389 | <mloskot>so, I'd assume bins are compatible |
| | 390 | |
| | 391 | }}} |
