Changes between Version 4 and Version 5 of PscMeeting20071205


Ignore:
Timestamp:
12/05/07 11:41:28 (17 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PscMeeting20071205

    v4 v5  
    1212
    1313== Agenda ==
     14
    1415 * Incubation Status
    1516 * FDO 3.3.0 Beta
     
    2021 * Proposal for provider for SQL Server 2008 spatial
    2122 * How to kick start discussion on posted futures topics
     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}}}