Changes between Version 16 and Version 17 of PscMeeting200801


Ignore:
Timestamp:
03/20/08 12:10:32 (17 years ago)
Author:
gregboone
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PscMeeting200801

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