| | 23 | |
| | 24 | == Transcript == |
| | 25 | |
| | 26 | |
| | 27 | {{{ |
| | 28 | |
| | 29 | <gregboone> Hi Frank, Mat, Orest, Zak |
| | 30 | <orest> Hi Greg. |
| | 31 | <FrankW> Hi gregboone |
| | 32 | <zjames_> hi |
| | 33 | <gregboone> I guess it is that time. |
| | 34 | <gregboone> I was hoping Bob would make it. |
| | 35 | <mloskot> hi |
| | 36 | <gregboone> Hopefully he will join a little later |
| | 37 | <gregboone> OK. If we all are ready, we can start |
| | 38 | <FrankW> Do we have an agenda? |
| | 39 | * FrankW finds http://trac.osgeo.org/fdo/wiki/PscMeeting20071205 |
| | 40 | <gregboone> Yes. That is the agenda |
| | 41 | -->| CIA-26 (n=CIA@208.69.182.149) has joined #FDO |
| | 42 | <gregboone> Lets start with the first topic of discussion. Incubation status. |
| | 43 | <orest> OK. |
| | 44 | <gregboone> We have made some progress on that front. The contributor agreements have been approved |
| | 45 | <gregboone> I still need to talk to Bob concerning where to send them |
| | 46 | <orest> Bob said that he will be 5 minutes late. |
| | 47 | <gregboone> I am willing to accept them , but he may have a more centralized idea in mind for FDO/MapGuide |
| | 48 | <gregboone> We can defer this discussion until Bon joins |
| | 49 | <mloskot> After the agreement is accepted, we (contributors) are supposed to sign and fax them to Autodesk, am I correct? |
| | 50 | <gregboone> That is yet to be determined. |
| | 51 | <mloskot> ok |
| | 52 | <gregboone> but we have discussed that as an option |
| | 53 | <gregboone> Also to do with the incubation, I have the update of the King copyright info on my TODO list |
| | 54 | <FrankW> gregboone: is this just adding appropriate headers? |
| | 55 | <gregboone> Yes |
| | 56 | <mloskot> What about keeping information about original author of a file in header? Is this specified by incubation reqs? |
| | 57 | <mloskot> IOW, should we track information about file authors in comment block of a file? |
| | 58 | <gregboone> I am not opposed to that, but it is not on my radar at this time. |
| | 59 | <FrankW> The Copyright line should reflect the copyright holder, which might be the original author, if that is what you mean. |
| | 60 | <mloskot> So, Copyright information is the only required details |
| | 61 | <mloskot> Author is not, even if Copyright holder != Author |
| | 62 | <FrankW> well, it isn't required now. We (fdo) have no standards on headers as far as I know. |
| | 63 | <mloskot> understood |
| | 64 | <gregboone> FrankW: Once we get these items addressed, how can we move the process forward with the incubation committee? |
| | 65 | <mloskot> it's clear now. I just thought it's regulated by incubation somehow |
| | 66 | <FrankW> gregboone: danmo would do a review, and if he is happy propose a motion to graduate to the incubator. |
| | 67 | <FrankW> I've poked danmo in case he can pop in. |
| | 68 | <gregboone> There was the understanding that a couple of months of further incubation was required. Do you think we are now beyond that point? |
| | 69 | <FrankW> I think we are getting there. |
| | 70 | <gregboone> :) |
| | 71 | <FrankW> But we should still dot our i's and cross our t's with regard to provenance, contributor agreements etc. |
| | 72 | <FrankW> (IMHO) |
| | 73 | <FrankW> Daniel's opinion matters more than mine. |
| | 74 | <FrankW> I wouldn't object to FDO graduating at this point. |
| | 75 | <gregboone> The provenance is 98% complete. There is a few small issues with respect to GDAL and ArcSDE |
| | 76 | <gregboone> regarding their test data |
| | 77 | <FrankW> right |
| | 78 | <gregboone> I was trying to avoid pulling the data out, but it may just come to tahta |
| | 79 | <gregboone> (that) |
| | 80 | -->| rbray (n=chatzill@adeskout.autodesk.com) has joined #FDO |
| | 81 | <gregboone> I actively looked for replacement data, but have not yet found all I need |
| | 82 | <gregboone> Hi Bob |
| | 83 | <rbray> Sorry I am late, hi all. |
| | 84 | <gregboone> Regarding contributor agreements, was there a new proposal on where they should be sent? |
| | 85 | <rbray> No I think we decided to leave it alone and just coordinate. |
| | 86 | <rbray> Still need to setup a Contributor Page |
| | 87 | <rbray> To track all that. |
| | 88 | <gregboone> Should we discuss the details off-line? I am not sure this is the forum |
| | 89 | <rbray> Yes that is fine. |
| | 90 | <gregboone> To end this thread, I will contact Daniel on nominating FDO for graduation |
| | 91 | <gregboone> Next in the Agenda is the FDO 3.3.0 Beta |
| | 92 | <gregboone> I have posted the tar files, updated the osgeo site and sent out a notice |
| | 93 | <gregboone> The beta is based on FDO build S019 |
| | 94 | <FrankW> was the notice very recent? I don't recall seeing it. |
| | 95 | <gregboone> It was sent to fdo-announce. |
| | 96 | <FrankW> ah, perhaps I am not subscribed. |
| | 97 | <FrankW> I'd encourage also cc:ing to fdo-internals. |
| | 98 | <gregboone> I will do that |
| | 99 | <gregboone> The MapGuide team plan to use the beta in their 2.0.0 beta |
| | 100 | <gregboone> The are integrating and testing now I believe |
| | 101 | <gregboone> I encourage all to try the beta and see if there are any issues. |
| | 102 | <gregboone> Any comments on the beta? |
| | 103 | <FrankW> cool, I see the builds include the python support. Perhaps can test a bit through that. |
| | 104 | <FrankW> It would be awfully nice if we could have fdo2fdo or some other tools in fdo binary releases for using fdo. |
| | 105 | * FrankW fails to poke haris... |
| | 106 | <mloskot> I'm testing FDO SVN with MG beta this week |
| | 107 | <gregboone> Yes. I believe there are a few bugs in the python wrappers. It would be good to test them further. |
| | 108 | <mloskot> still have to have test a lot of issues in the postgis provider. |
| | 109 | <gregboone> The King providers are not part of the beta |
| | 110 | <gregboone> That is unfortunate at this point. |
| | 111 | <rbray> Any idea when they will be? |
| | 112 | <gregboone> I would like to see some movement there |
| | 113 | * mloskot has no idea |
| | 114 | <orest> What is holding them up? |
| | 115 | <gregboone> I was hoping Harris would move those providers forward and test |
| | 116 | <FrankW> Is the problem that they don't build easily? |
| | 117 | <FrankW> Obviously they are fairly widely used. |
| | 118 | <gregboone> Yes. Part of the issue is the build process |
| | 119 | <mloskot> I'm not sure but AFAIR Harris does not use SVN frequently |
| | 120 | <mloskot> but updates the King once a month or so |
| | 121 | <gregboone> We need to migrate the King build process to be consistent with the general build process |
| | 122 | <mloskot> Perhaps he has working/better version on his laptop, so he can just push it to the mainstream |
| | 123 | <gregboone> At FOSS4G he mentioned that a second developer was working on the Oracle provider |
| | 124 | <gregboone> And that a push was in the works |
| | 125 | <gregboone> However, I have not seen any activity |
| | 126 | <FrankW> I'm also interested in getting fdorastutil (http://svn.osgeo.org/fdo/trunk/Tools/fdorastutil/) into release builds. |
| | 127 | <FrankW> But I'm not exactly savvy about creating windows build stuff. |
| | 128 | <gregboone> I can look into that |
| | 129 | <gregboone> fdo2fdo is not in the SVN correct? |
| | 130 | <FrankW> Not yet, it seems. |
| | 131 | <FrankW> Put it would (when contributed) go into /Tools. |
| | 132 | <gregboone> Correct |
| | 133 | <rbray> Yes tools is where we discussed putting it |
| | 134 | <gregboone> OK. Please forward an y ideas on contributions to the beta or the release process to me on fdo-internals |
| | 135 | <FrankW> ok |
| | 136 | <gregboone> Moving on to the GDAL 1.4.4 update |
| | 137 | <gregboone> I have submitted the update. It is part of the beta |
| | 138 | <gregboone> Do we need t do anything else for ecw/mrsid support? |
| | 139 | <FrankW> Do the updated plugins I provided work? |
| | 140 | <gregboone> I have not tested those. |
| | 141 | <FrankW> I'm still somewhat confused about this whole VC8/patchlevel dll issue. |
| | 142 | <FrankW> But if it doesn't affect folks using the dll's I produced then I guess it is ok. |
| | 143 | <gregboone> The SP1 issue? |
| | 144 | <FrankW> If it does, I either need toupdate or someone else has to build the plugins. |
| | 145 | <FrankW> gregboone: right |
| | 146 | <mloskot> gregboone: am I correct, that FDO/MG teams migrated to SP1 ? |
| | 147 | <gregboone> I believe we will need to build the plugins against SP1 |
| | 148 | <FrankW> In particular, folks shouldn't have to replace gdal14.dll with the one I made. |
| | 149 | <gregboone> Right |
| | 150 | <FrankW> Grr |
| | 151 | <FrankW> Perhaps I will consult with mloskot offline for advice on upgrading to SP1. ARe you using SP1 mloskot? |
| | 152 | <gregboone> More testing is required to finalize that belief |
| | 153 | <mloskot> FrankW: yes, I do |
| | 154 | <FrankW> (or I may beg mloskot to build the plugins) |
| | 155 | <mloskot> FrankW: no begging is needed, just tell me :-) |
| | 156 | <gregboone> I know that the SP1 redistributable was required to be installed at Foss4G in order for FDO to run. |
| | 157 | <mloskot> gregboone: right, VS2005+SP1 requires users to use new redist package |
| | 158 | <mloskot> SP1 is like new version of VS2005 :-) |
| | 159 | <gregboone> OK. Mat will look into generating new plugins for the GDAL provider |
| | 160 | <mloskot> yup |
| | 161 | <gregboone> Let us know if the GDAL binary shipped with FDO is ok to run with the plugins |
| | 162 | <gregboone> Lets move on to Boost |
| | 163 | <gregboone> The latest version has been submitted, but the footprint is large |
| | 164 | <gregboone> Ideas? |
| | 165 | <mloskot> 1. use system/user's version of boost |
| | 166 | <mloskot> 2. use bcp utility to generate subset of boost libraries |
| | 167 | <mloskot> 3. Windows users can use available binaries |
| | 168 | <mloskot> 4. Linux users have binaries too as packages |
| | 169 | <gregboone> The general rule for FDO Thirdparty is to ship all dependant library source code where possible |
| | 170 | <mloskot> Option 3 means boost lives in FDO tree |
| | 171 | <mloskot> ** Option 2 |
| | 172 | <mloskot> 1, 3, 4 - external libs |
| | 173 | <gregboone> We can prune the boost tree to just include datetime and thread source |
| | 174 | <gregboone> We could always add new boost components as required |
| | 175 | <gregboone> I think that options 1,3, 4 are harder to maintain |
| | 176 | <mloskot> Honestly, using boost is very simple the only need is to specify min required version |
| | 177 | <mloskot> so, I can't see what's harder in 1,3,4 |
| | 178 | <gregboone> I do not doubt that, but I am concerned that changing the process may make the user experience more difficult |
| | 179 | <mloskot> agreed |
| | 180 | <gregboone> Can we take option 2 and make a more flexible solution a longer term goal? |
| | 181 | <mloskot> gregboone: yes |
| | 182 | <mloskot> First, we need to identify what libraries we use |
| | 183 | <gregboone> thread and datetime is it |
| | 184 | <gregboone> no others |
| | 185 | <mloskot> Second, we run bcp (http://www.boost.org/tools/bcp/bcp.html) to extract all of them with dependencies |
| | 186 | <mloskot> gregboone: ok, so these are two binary libraries |
| | 187 | <mloskot> but there is number of headers-only libs used |
| | 188 | <gregboone> I see |
| | 189 | <mloskot> at least I use them as I love them :-) |
| | 190 | <mloskot> in PostGIS provider I mean |
| | 191 | <gregboone> Maybe an offline discussion on fdo-internals will clear up what is required |
| | 192 | <mloskot> gregboone: I can volunteer to try to do it |
| | 193 | <mloskot> to generated minimal boost package for FDO |
| | 194 | <gregboone> If you could, that would be great |
| | 195 | <mloskot> gregboone: let me to grep through FDO sources and identify libraries and extract them |
| | 196 | <mloskot> Then, I will post to the fdo-internals about results |
| | 197 | <gregboone> Agreed |
| | 198 | <gregboone> Let's skip sample code and move the discussion to Patched DLLs |
| | 199 | <mloskot> ok |
| | 200 | <mloskot> gregboone: one Q to Boost, could you report ticket for this task? |
| | 201 | <mloskot> or I can report? |
| | 202 | <gregboone> Please file one |
| | 203 | <mloskot> ok |
| | 204 | <gregboone> On patches... I posted a patch to the FDO ArcSDE provider on a new pathes page on fdo.osgeo.org |
| | 205 | <gregboone> The idea was that I wanted to separate the download of release versions as opposed to patches |
| | 206 | <gregboone> Is there any feedback on this aoproach? |
| | 207 | <FrankW> gregboone: you are talking about: http://trac.osgeo.org/fdo/wiki/SubmitPatch |
| | 208 | <FrankW> ? |
| | 209 | <zjames_> https://fdo.osgeo.org/patches.html |
| | 210 | <gregboone> https://fdo.osgeo.org/patches.html |
| | 211 | <gregboone> Franks link was more geared towards code sun=bmission |
| | 212 | <gregboone> submission |
| | 213 | <gregboone> I was looking to formalize a release process other than a full release |
| | 214 | <FrankW> This is an approach to provide binary patches post release? |
| | 215 | <gregboone> Yes |
| | 216 | <gregboone> We had several requests for a patch |
| | 217 | <gregboone> If there are suggestions on improving this process, I am open to all ideas |
| | 218 | <FrankW> Do you think it is necessary to provide debug versions for patch binaries? |
| | 219 | <gregboone> No.... but I wanted to be complete. |
| | 220 | <FrankW> Would it be up to the normal "builder" (ie. you) to prepare these binary patches? |
| | 221 | <gregboone> The whole issue of releasing debug binaries could be re-evaluated |
| | 222 | <FrankW> Or is it intended that anyone can prepare one and post it? |
| | 223 | <gregboone> The normal builder should prepare these |
| | 224 | <FrankW> I'm just wondering if we should aim for "reduced pain for producer", or completeness. |
| | 225 | <gregboone> I want to maintain a consistent binary source |
| | 226 | <FrankW> sounds good to me. Ensures consistency. |
| | 227 | <mloskot> #189 |
| | 228 | <gregboone> On Debug binaries, should we be releasing them? |
| | 229 | <fdotrac> Ticket #189: Generate minimal distribution of Boost libraries, http://trac.osgeo.org/fdo/ticket/189 |
| | 230 | <mloskot> gregboone: we can not release them |
| | 231 | <mloskot> if you mean release as publish debug binaries |
| | 232 | <mloskot> for Windows |
| | 233 | <gregboone> I mean debug versions of FDO binaries |
| | 234 | <mloskot> gregboone: we can not release them for Windows if built using VS, according to EULA attached to Visual Studio |
| | 235 | <gregboone> No.. I just meant the FDO binaries |
| | 236 | <mloskot> but compiled in debug mode, right? |
| | 237 | <gregboone> right |
| | 238 | <mloskot> that's what I'm talking about |
| | 239 | <gregboone> Ah... |
| | 240 | <FrankW> I'm not enamoured of distributing debug versions, but I don't object to it if I'm not the one preparing them. :-) |
| | 241 | <mloskot> "Redistributing debug VC++ programs is not permitted by the EULA. You can only do this for testing purposes internally. See the EULA for Visual Studio 2005." |
| | 242 | <mloskot> http://msdn2.microsoft.com/en-us/library/aa985617(VS.80).aspx |
| | 243 | <gregboone> Thanks for the link |
| | 244 | <gregboone> I will look at it and re-evaluate our process. |
| | 245 | <mloskot> gregboone: and Microsoft makes it hard to overcome by not publishing redistributable package of debug binaries |
| | 246 | <gregboone> Right you are. |
| | 247 | <mloskot> and by forbidding us to ship debug versions of runtimes |
| | 248 | <mloskot> etc. |
| | 249 | <mloskot> a lot of hacks ;-) |
| | 250 | <gregboone> We may have to remove links to our debug SDK tar files then. |
| | 251 | <mloskot> probably |
| | 252 | <mloskot> or may be you can leave them as for VS2005 owners only |
| | 253 | <mloskot> and not including debug runtimes |
| | 254 | <gregboone> That seems more confusing |
| | 255 | * mloskot is not a lawyer though |
| | 256 | <gregboone> We need a simple message |
| | 257 | <gregboone> Sorry to speed things up, can we discuss the RFC for the new SQLServer Provider? |
| | 258 | <gregboone> I have posted this as RFC 12 |
| | 259 | <gregboone> http://trac.osgeo.org/fdo/wiki/FDORfc12 |
| | 260 | <orest> I mentioned at the last PSC that Autodesk will contribute a provider for the new SQL Server 2008 spatial coming out sometime next year. |
| | 261 | <orest> We're working with a pre-beta version of it right now. |
| | 262 | <orest> RFC describes proposed capabilities and time-line. |
| | 263 | <mloskot> skimmed, looks great |
| | 264 | <gregboone> I am interested in hearing any feedback the community has. |
| | 265 | <gregboone> We are keen to make this provider a success |
| | 266 | <gregboone> Please post all comments to fdo-internals |
| | 267 | <FrankW> Does Haris have an SQLServer provider? Do we need to pick one that the PSC project "supports"? |
| | 268 | * mloskot has no technical comments, the RFC looks as complete and well-written. +1 |
| | 269 | <orest> We plan fairly complete capabilities: read/write, existing schema access and modification, all geom types and spatial operators available from the server, ... |
| | 270 | <FrankW> I certainly have no objections to RFC 12 |
| | 271 | <gregboone> We should support one as a supported PSC project |
| | 272 | <gregboone> Harris' provider does not support SQL Server 2008. |
| | 273 | <gregboone> At least not the native geometry format |
| | 274 | <FrankW> Ah, it is for non-spatial earlier versions? |
| | 275 | <FrankW> Gotcha |
| | 276 | <FrankW> Well, I'm all for rfc12. |
| | 277 | <orest> Our Product Manager spoke with Harris about our plans at FOSS4g and heard that he was supportive of this, would contribute after we posted our code. |
| | 278 | <gregboone> If there are no objections and we have general support, I motion that we accept RFC 12 |
| | 279 | <FrankW> Should rfc motions be happening on the mailing list? |
| | 280 | <gregboone> Can I get a seconder on that motion? :) |
| | 281 | <gregboone> It can happen on the mailing list if that is desired |
| | 282 | <FrankW> We take that practice in other projects though I haven't reviewed the fdo psc doc. |
| | 283 | <orest> I'll second. |
| | 284 | <orest> Mailing list would be good since not all members of psc made it today. |
| | 285 | <FrankW> I don't see that we are in a huge hurry, and it gives folks who aren't here an opportunity to comment. |
| | 286 | <gregboone> OK. I will make the motion there. |
| | 287 | <gregboone> Do we have time to discuss futures? |
| | 288 | <mloskot> hehe, no I see what's reasonable time to develop new FDO provider :) |
| | 289 | <gregboone> :) |
| | 290 | <mloskot> gregboone: what do futures include? |
| | 291 | <orest> I added this bullet. |
| | 292 | <gregboone> mloskot: any topic on the futures page |
| | 293 | <orest> We had posted a number of futures topics a few weeks ago ... |
| | 294 | <FrankW> BTW, would it be possible to write some details on time, etc into the 3.3.0 roadmap info? |
| | 295 | <FrankW> http://trac.osgeo.org/fdo/roadmap |
| | 296 | <orest> and haven't received too much feedback yet. |
| | 297 | <gregboone> I am most interested in the new client layer we discussed at FOSS46 |
| | 298 | <gregboone> I will take the roadmap update on my plate |
| | 299 | <orest> I don't think anyone has added comments yet. So, maybe today, this is just a reminder to review the futures topics and add comments, suggestions, additions, ... |
| | 300 | <mloskot> I don't have any comments to futures, but I'd like to see FDO utilities |
| | 301 | <mloskot> in future |
| | 302 | <mloskot> simple command line programs |
| | 303 | <orest> mloskot: Have a look at the first topic on client utilities. It may overlap what you're looking for. |
| | 304 | <mloskot> orest: yes, that's the document I'm referring |
| | 305 | <mloskot> I will give detailed feedback to it |
| | 306 | <orest> That would be great. Thanks. |
| | 307 | * FrankW digs into the client utilities topic... |
| | 308 | <gregboone> I encourage all PSC and community members to provide feedback on the client utilities topic so we can plan for the future releases of FDO |
| | 309 | <rbray> SDF as a standard OSGeo File format is another topic for sometime. |
| | 310 | <FrankW> But it still doesn't seem to be about commandline/gui tools. Darn. |
| | 311 | <mloskot> SDF +1 |
| | 312 | <orest> Frank W: Go ahead and add commandline/gui topics to futures list. |
| | 313 | <gregboone> I will add the SDF topic as an agenda item for the next meeting. |
| | 314 | <gregboone> We have run past our alloted time. |
| | 315 | <rbray> Could we use the fdo2fdo code to create some command line utilities. |
| | 316 | <FrankW> rbray: that was my thought at one point. |
| | 317 | <mloskot> isn't fdo2fdo in .NET ? |
| | 318 | <gregboone> Not sure if that is the most flexible approach. |
| | 319 | <rbray> Shows what I know, it might be. |
| | 320 | <FrankW> Ah, I thought there was some sort of core that wasn't but I may be confused. |
| | 321 | <FrankW> I've yet to see the actual code. |
| | 322 | <FrankW> Well, I've got a date with my daughter to work on the snow fort... |
| | 323 | * mloskot too |
| | 324 | <gregboone> Well... I would like to wrap up the meeting. :) We can discuss sample code and utilities again at the next meeting |
| | 325 | <mloskot> agreed, |
| | 326 | <gregboone> Thanks all for joining |
| | 327 | <mloskot> Thanks! |
| | 328 | <FrankW> later folks! |
| | 329 | <orest> Frank W: Sounds like fun! |
| | 330 | <gregboone> I will update the PSC link with a list of action items |
| | 331 | <gregboone> Bye all |
| | 332 | |
| | 333 | |
| | 334 | }}} |
