| | 1 | [wiki:ProjectSteeringCommittee Project Steering Committee - Home] |
| | 2 | |
| | 3 | == Meeting Info == |
| | 4 | |
| | 5 | The third meeting of the FDO PSC will take place on 10-24-2007. |
| | 6 | |
| | 7 | Meeting Chair: Greg Boone |
| | 8 | |
| | 9 | Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?year=2007&month=10&day=24&hour=17&min=0&sec=0 |
| | 10 | |
| | 11 | Location: The meeting will be held on IRC at [irc://irc.freenode.net/fdo #fdo] |
| | 12 | |
| | 13 | == Agenda == |
| | 14 | * Incubation Status |
| | 15 | * Review contributor agreement status |
| | 16 | * Updated Source Code [http://wiki.osgeo.org/index.php/FDO_Provenance_Review Provenance Review] |
| | 17 | * Proposed release schedule for FDO 3.3.0 (see [http://fdo.osgeo.org/roadMap.html FDO Road Map]) |
| | 18 | * RFCs |
| | 19 | * RFC XX - WMS !FormatType -- TDB |
| | 20 | * Thirdparty Source Code Updates |
| | 21 | * GDAL/OGR 1.4.3 |
| | 22 | * Adoption of New FDO Providers |
| | 23 | * FDO provider for NEN1878 |
| | 24 | |
| | 25 | == Transcript == |
| | 26 | |
| | 27 | |
| | 28 | {{{ |
| | 29 | -->| orest (n=chatzill@12.160.193.229) has joined #fdo |
| | 30 | <gregb> Hi Orest |
| | 31 | -->| rbray (n=chatzill@adeskout.autodesk.com) has joined #fdo |
| | 32 | -->| danmo (n=dmorisse@157-146.svr.royaume.com) has joined #fdo |
| | 33 | <gregb> Hi Bob |
| | 34 | <rbray> Hey Greg |
| | 35 | <gregb> So, I see Orest and Bob, who else is online? |
| | 36 | <mloskot> Hi all |
| | 37 | <gregb> Hi Mateusz |
| | 38 | -->| RobertF (n=RobertF@12.160.193.229) has joined #fdo |
| | 39 | -->| FrankW (n=warmerda@dpc674728121.direcpc.com) has joined #fdo |
| | 40 | * mloskot is calling Frank |
| | 41 | <mloskot> ah, cool |
| | 42 | -->| jasonbirch (n=jasonbir@osgeo/member/jasonbirch) has joined #fdo |
| | 43 | * danmo here |
| | 44 | * FrankW multiplexes between foss4g and fdo meeting. :-) |
| | 45 | -->| HarisK (n=chatzill@84-255-254-95.static.dsl.t-2.net) has joined #fdo |
| | 46 | <HarisK> Hi |
| | 47 | <gregb> Orest is asking if his posts can be seen.... |
| | 48 | <orest> Hi. |
| | 49 | <orest> Hi Greg. |
| | 50 | <gregb> There we are |
| | 51 | <RobertF> Hi |
| | 52 | <gregb> I think the entire PSC is here, shall we begin? |
| | 53 | <orest> Sure. |
| | 54 | <jasonbirch> Howdy |
| | 55 | <gregb> The first topic should be incubation |
| | 56 | <mloskot> yup |
| | 57 | <gregb> I have received a new contributor agreement from Bon |
| | 58 | <gregb> Bob |
| | 59 | <gregb> I am reviewing it and will post to the internals alias shortly |
| | 60 | <gregb> We then will need to ensure that all appropriate parties have signed |
| | 61 | <rbray> Greg, we need to review that and motion to adopt them. |
| | 62 | <gregb> Agreed |
| | 63 | <gregb> I will make that motion once all parties have had a chance to review |
| | 64 | <mloskot> Perhaps, i've lost the subject, but I've not signed FDO or OSGeo Foundation contributor agreement |
| | 65 | <mloskot> that's listed here |
| | 66 | <mloskot> http://fdo.osgeo.org/developer.html |
| | 67 | <gregb> Once the new agreement is adopted, you will be expected to sign |
| | 68 | <gregb> That link is out of date |
| | 69 | <mloskot> understood |
| | 70 | <gregb> The second issue for incubation is the provenace review |
| | 71 | <gregb> I have updated the online document |
| | 72 | <gregb> We have some outstanding issues surrounding raster test data |
| | 73 | <gregb> I am unsure how to proceed on those files |
| | 74 | <FrankW> I am willing to "speak on behalf of" a bunch of the files. |
| | 75 | <FrankW> For others, it might be sufficient for an ADSK rep to state they believe they have rights to use and redistribute them even if detailed history is unclear. |
| | 76 | <FrankW> And we should make it clear that detailed licenses are not clear for the files, though we believe we have rights to redistribute. |
| | 77 | <gregb> That may also prove difficult |
| | 78 | <gregb> The sources of some files have become lost |
| | 79 | <FrankW> What we aren't willing to "speak for" we should remove and re-engineer the tests to use other similarly organized data. |
| | 80 | <gregb> Agreed |
| | 81 | <FrankW> Was ADSK careful that it had rights to use and distribute it's internal test data? |
| | 82 | <gregb> I would state that there is some possibility that some files were not validated |
| | 83 | <FrankW> I will update the prov. review with regard to files I'm comfortable with speaking on behalf of. |
| | 84 | <gregb> Great |
| | 85 | <gregb> I have updated the incubation status page as well as the coding standards reference |
| | 86 | <FrankW> And I'm willing to do some engineering to replace some other test files with safe to distribute ones that achieve the same unittest functionality. |
| | 87 | <FrankW> though there may be limits. :-) |
| | 88 | |<-- rbray has left irc.freenode.net (Read error: 104 (Connection reset by peer)) |
| | 89 | <gregb> We need to revisit the incubation page once the raster image history is addressed |
| | 90 | <FrankW> Are the non-raster data files all sanctionable? |
| | 91 | <gregb> I believe so, but the SHP data also should be re-checked |
| | 92 | <gregb> Just to be sure |
| | 93 | <RobertF> Didn't we check on that before submitting to OS? |
| | 94 | <gregb> Yes, but a secondary check wouldn't be a bad idea |
| | 95 | <gregb> We dumped a lot of data into SVN in a hurry |
| | 96 | <gregb> Until we get a handle on the testdata, we should not distribute the testdata tar files |
| | 97 | <RobertF> That was not my understanding and it needs to be corrected. |
| | 98 | <gregb> Agreed. I will take care of re-checking the SHP data |
| | 99 | <FrankW> gregb: I don't think we need to strip stuff out in advance of review and remediation. |
| | 100 | <FrankW> Though I may not be as risk adverse as ADSK. :-) |
| | 101 | <gregb> Agreed. but the testdata is released as a separate tar file now |
| | 102 | <FrankW> Ah, I didn't realize that. |
| | 103 | <jasonbirch> Which is a good change... |
| | 104 | <gregb> Wwe can delay the release until we are comfortable |
| | 105 | <jasonbirch> Yeah, most people don't run the tests anyway ;) |
| | 106 | <mloskot> lol |
| | 107 | <gregb> (Actually, it is a number of tar files, one for each provider) |
| | 108 | <gregb> :-) |
| | 109 | <gregb> Can we discuss the FDO readmap? |
| | 110 | <gregb> roadmap |
| | 111 | <mloskot> +1 |
| | 112 | <gregb> The fdo.osgeo.org site has been updated to contain the details of the 3.3.0 release schedule |
| | 113 | <orest> Yes, saw that. |
| | 114 | <gregb> With dates for an alpha, beta, candidate, etc |
| | 115 | <mloskot> http://fdo.osgeo.org/roadMap.html |
| | 116 | <RobertF> This was just a proposal. |
| | 117 | <gregb> What is the impression of the PSC? |
| | 118 | <mloskot> I have to confess, I like the idea about Beta in Dec :-) |
| | 119 | <RobertF> There is also the request to have a 3.3.0 in october and 3.3.1 in February for MGOS. |
| | 120 | <gregb> Agreed |
| | 121 | <FrankW> looks ok to me. |
| | 122 | <jasonbirch> Heh, so MapGuide is going to release with a pre-alpha version of FDO... |
| | 123 | <mloskot> gregb: my impression is "it works for me" and "gives a chance to bring updated PostGIS provider with 3.3.0" |
| | 124 | <gregb> They will put out their beta with our alpha |
| | 125 | <RobertF> That's the problem for MGOS. They can't release on Beta and they are targetting 3.3 branch. |
| | 126 | <RobertF> Has this been agreed with MG team? |
| | 127 | <mloskot> Perhaps I don't understand the connection between MGOS and FDO well, but MG is a client so it should follow the roadmap of FDO, but not the other way. Am I correct? |
| | 128 | <mloskot> I just would like to be explained. |
| | 129 | <jasonbirch> MapGuide can choose to release with FDO trunk or alpha if it wants. |
| | 130 | <FrankW> It is an important client that had best support well. |
| | 131 | <jasonbirch> I have a feeling that Tom wouldn't be happy with it though. |
| | 132 | <jasonbirch> Given his stance on GEOS3 |
| | 133 | <jasonbirch> I think the timing on the betas and rcs is a bit wide... |
| | 134 | <gregb> Well, I do not believe that the release schedule for FDO can be advanced beyond the postyed dates |
| | 135 | <jasonbirch> Is this because of additional functionality? |
| | 136 | <jasonbirch> Or because of internal ADSK QA schedules? |
| | 137 | <orest> What's the current date for MG beta? |
| | 138 | <jasonbirch> A week ago :) |
| | 139 | <orest> I missed it! |
| | 140 | <RobertF> They shipped on S013 build which we didn;t post yet. |
| | 141 | <jasonbirch> didn't happen :) |
| | 142 | <gregb> I am not in favour of releasing FDO without a beta |
| | 143 | <RobertF> I agree. |
| | 144 | <gregb> and we need to leave time between the beta and candidates for testing, etc |
| | 145 | <orest> Agree. |
| | 146 | <jasonbirch> Me neither |
| | 147 | <mloskot> MG 2.0 is planned to Nov 30 |
| | 148 | <mloskot> as I see. |
| | 149 | <gregb> That is very tight for us. |
| | 150 | <jasonbirch> I don't think the roadmap is accurate mloskot |
| | 151 | <mloskot> jasonbirch: ok |
| | 152 | <jasonbirch> Too bad Bob left... |
| | 153 | <jasonbirch> The MapGuide timing is 2 weeks between betas and RCs generally... |
| | 154 | <gregb> He lost his connection |
| | 155 | <jasonbirch> Snowstorm probably ;) |
| | 156 | <mloskot> Folks, perhaps we can collect comments/votes for the roadmap as a preliminary voting and if we like it, we can discuss it with MG team |
| | 157 | <mloskot> apply changes |
| | 158 | <mloskot> re-vote |
| | 159 | <HarisK> I think once was already mentioned relationship between FDO version and provider's version's |
| | 160 | <gregb> At this point it is November, to advance the cycle, we would need to skip the alpha |
| | 161 | <jasonbirch> http://mapguide.osgeo.org/releaseprocess.html |
| | 162 | <gregb> And possibly one of the cadidates |
| | 163 | <HarisK> Am I right if I am looking at it that provider's has it's own development rate |
| | 164 | <mloskot> gregb: my question is, does it (one month advance) change anything ? |
| | 165 | <mloskot> stable release is planned to march 2008 |
| | 166 | <mloskot> if MG stable is planned earlier, I don't think skipping changes anything here |
| | 167 | <gregb> It is a matter of testing |
| | 168 | <jasonbirch> Yes... |
| | 169 | <mloskot> ok |
| | 170 | <FrankW> HarisK: I think a provider could have some of it's own releases within a given FDO stable version framework. Is that your point? |
| | 171 | <HarisK> yes and also supporting different version's of FDO spec |
| | 172 | <mloskot> huh, challenging |
| | 173 | <FrankW> HarisK: I'm ok with a "trunk" provider retaining compilability under older versions of FDO. |
| | 174 | <gregb> Ok, so is there any proposal to change the posted schedule? |
| | 175 | <jasonbirch> It would be nice if MG and FDO weren't on the same development-push cycle, but I don't see that happening soon. |
| | 176 | <RobertF> This was suggested before but it does require lot of time to maintain multiple branch. |
| | 177 | <gregb> If not, we can vote to adopt and bring it to the MapGuide team for discussion |
| | 178 | <jasonbirch> Somehow we need to figure out what FDO needs to do. I can't speak to test cycles, but would cutting the time between iterations to 2-3 weeks help? |
| | 179 | <mloskot> gregb: +1 |
| | 180 | <gregb> 2 weeks is not much time. |
| | 181 | <gregb> 3 maybe ok |
| | 182 | <mloskot> I agree with gregb |
| | 183 | <jasonbirch> Either case, I don't think it helps MapGuide. This version of OS is likely to ship with an untested version of FDO... |
| | 184 | <jasonbirch> Either that or be delayed. |
| | 185 | <gregb> Agreed |
| | 186 | <HarisK> are there any breaking changes in 3.3 ? |
| | 187 | <gregb> There is one known issue with WMS |
| | 188 | <mloskot> new GDAL |
| | 189 | <jasonbirch> New GDAL breaks stuff? |
| | 190 | <mloskot> and new providers |
| | 191 | <gregb> I have emailed the internals group with detailes on RFC 10 |
| | 192 | <HarisK> but no new FDO spec ? |
| | 193 | <FrankW> new gdal should not break stuff. |
| | 194 | <mloskot> jasonbirch: no |
| | 195 | <gregb> New providers are ok |
| | 196 | <HarisK> I don't see new providers as new version's of FDO |
| | 197 | <jasonbirch> No, me neither... |
| | 198 | <FrankW> HarisK: by breaking do you mean api changes of any kind or just changes that would break old code? |
| | 199 | <FrankW> I think most api adjustments have not had serious backward compatability issues. |
| | 200 | <HarisK> I mean if like api changes which will not allow older providers to run |
| | 201 | <HarisK> yes, ok |
| | 202 | <gregb> A recompilation of the providers will be required for use with 3.3.0 |
| | 203 | <gregb> If I understand correctly |
| | 204 | <gregb> To move the meeting along, is there agreement on the schedule? |
| | 205 | <FrankW> I'm ok with it. |
| | 206 | <jasonbirch> Sure. As long as you are convinced that advancing the schedule would add unacceptable risk, then I'm OK iwth it. |
| | 207 | <gregb> Robert? Can you comment? |
| | 208 | <HarisK> I was also thinking that we can do it quicker if neede for MG |
| | 209 | <mloskot> I'm OK too |
| | 210 | <HarisK> Changes in 3.3 as far as I know are not big, mostly addition's which will not change existing providers |
| | 211 | <mloskot> HarisK: so you mean it should be safe for MG to use pre-release version of FDO in their release, do I understand it correctly? |
| | 212 | <HarisK> No, I thaught that we could perhaps speed up regarding 3.3 |
| | 213 | <orest> But any place where MG uses new additions would require enough time for testing. |
| | 214 | <jasonbirch> Only if it's accepted that there will be a 3.3.1 for March I think... |
| | 215 | <mloskot> HarisK: I see |
| | 216 | <HarisK> if some specific provider need more time later than he can be released again |
| | 217 | <gregb> I am warry stating that anything is safe, without some time for testing |
| | 218 | <gregb> The risk is there |
| | 219 | <gregb> We could do a release candidate in December |
| | 220 | <gregb> If that goes well, release 3.3.0 in January |
| | 221 | <mloskot> so, generally, you mean we're flexible but what we are supposed to agree with now? |
| | 222 | <RobertF> There will be changed after January - they will go in 3.3.1? |
| | 223 | <mloskot> The current written roadmap or this new changes? |
| | 224 | <gregb> RobertF: Yes |
| | 225 | <mloskot> I see |
| | 226 | <jasonbirch> Point releases generally shouldn't include new features, I think... |
| | 227 | <jasonbirch> Large changes? |
| | 228 | <RobertF> Then we probably need a 3.3.1 somewhere by March. |
| | 229 | <jasonbirch> Additions? API changes? Bug fixes? |
| | 230 | <mloskot> I think bug fixes and eventually some updates in providers only |
| | 231 | <gregb> There should ne no API changes in a point release |
| | 232 | <RobertF> Bug fixes only. |
| | 233 | <jasonbirch> Works for me... |
| | 234 | <orest> That's the way I understand it too - bug fixes only |
| | 235 | <orest> But, is it the release date that is the issue? I thought it was mostly beta date that was the issue? |
| | 236 | <FrankW> Note, we have made API compatible feature improvements within providers in point releases in the past. Not sure if we will keep doing this or not. |
| | 237 | <mloskot> I agree, but if we are changing the roadmap by skipping some milestones, then |
| | 238 | <mloskot> perhaps we could leave some backdoors to let updates in providers |
| | 239 | <mloskot> exceptionally for this roadmap |
| | 240 | <jasonbirch> I don't think that we should constrain providers to not change at all in point releases. Non-API changes should be OK. |
| | 241 | <mloskot> +1 |
| | 242 | <gregb> Agreed |
| | 243 | <jasonbirch> But major features should be avoided too, because testing requirements would skyrocket :) |
| | 244 | <mloskot> Agreed |
| | 245 | <orest> Right, improvements to existing functionality is ok, but not new functionality / capability. |
| | 246 | <gregb> Agreed |
| | 247 | <mloskot> Summarizing: |
| | 248 | <mloskot> - no provider's API change |
| | 249 | <mloskot> - no new features |
| | 250 | <mloskot> EOF |
| | 251 | <jasonbirch> So. What's changing in the release cycle then? |
| | 252 | <gregb> The proposal is a release in January |
| | 253 | <gregb> With a candidate in December |
| | 254 | <jasonbirch> Beta in November then? |
| | 255 | <gregb> Yes. Alpha may be possible if we go out with it this week |
| | 256 | <jasonbirch> Any chance of getting GDAL 1.4 into that? |
| | 257 | <orest> It's kind of loose to say November / December, etc. Don't we need to pin down calendar day or week? |
| | 258 | <jasonbirch> I mean 1.4.3? Does it exist yet? |
| | 259 | <gregb> 1.4 is in the alpha. But not 1.4.3 |
| | 260 | <FrankW> 1.4.3 does not exist yet, but one hopes it will within a few days. |
| | 261 | <gregb> We can assign firm dates to the releases |
| | 262 | <gregb> We probably can do that offline (fdo-internals) |
| | 263 | <jasonbirch> I think that as long as we have general agreement, it's OK for Greg to come up with the firm dates? |
| | 264 | <gregb> I can do that |
| | 265 | <gregb> I will work on getting the current build posted as an aplha as well |
| | 266 | <jasonbirch> Unless Haris has something major going on with FDO that he wants to fit in? I don't think that either mloskot or FrankW do right now? |
| | 267 | <HarisK> no |
| | 268 | <FrankW> neither I. |
| | 269 | <mloskot> neither I |
| | 270 | <gregb> I motion that we adopt the proposal to release 3.3.0 in January, with a candidate in December, and a beta in December |
| | 271 | <gregb> beta in November |
| | 272 | <jasonbirch> Seconded and +1 |
| | 273 | <mloskot> +1 |
| | 274 | <HarisK> +1 |
| | 275 | <FrankW> +1 |
| | 276 | <orest> +1 |
| | 277 | <gregb> The motion is carried |
| | 278 | <gregb> I will come up with the dates and send them out |
| | 279 | <mloskot> gregb: thanks! |
| | 280 | <gregb> Do we have time to discuss new providers? |
| | 281 | <jasonbirch> I've got another 15 minutes :) |
| | 282 | <orest> I have time. |
| | 283 | <FrankW> I have time. |
| | 284 | <HarisK> me too |
| | 285 | <gregb> There has been some interest on a provider for NEN1878 |
| | 286 | <mloskot> I have time |
| | 287 | <gregb> We are waiting for some more information. |
| | 288 | <gregb> Is there anything we need to do here? |
| | 289 | <FrankW> Is there a committer willing to do evaluation of the NEN1878 provider? |
| | 290 | <gregb> I have volunteered to provide guidance, but a review may need more attention |
| | 291 | <HarisK> I can do it |
| | 292 | <HarisK> I understand they already have a working verison of it |
| | 293 | <gregb> We should touch base with them again to encourage movement on the RFC |
| | 294 | <orest> Do we have a detailed list of capabilities yet? |
| | 295 | <gregb> No |
| | 296 | <HarisK> I saw just one email explaining what it is |
| | 297 | <FrankW> I'm pleased to leave this to gregb and HarisK. If the provider looks good we can hopefully bring in the developer as a committer. |
| | 298 | <HarisK> Cadastral data exchange file |
| | 299 | <gregb> Agreed |
| | 300 | <HarisK> ok |
| | 301 | <mloskot> Agreed |
| | 302 | <gregb> Are there other providers in development that we know about? |
| | 303 | <HarisK> or not know :) |
| | 304 | <gregb> lol |
| | 305 | <FrankW> Are folks at 1spatial working on provider(s) |
| | 306 | <orest> I will be sending out a discussion soon on work we're starting on SQL Server 2008, which will have native spatial data types. |
| | 307 | <FrankW> (that was supposed to be a question) |
| | 308 | <jasonbirch> orest: will that be proprietary? |
| | 309 | <orest> No. |
| | 310 | <jasonbirch> Oh, cool... |
| | 311 | <orest> At least until the API from Microsoft becomes public. |
| | 312 | <gregb> FrankW: I am not aware of any effort from 1Spatial. I will touch base with Peter R to verify |
| | 313 | <HarisK> I know they are using King.Oracle |
| | 314 | <gregb> Concerning King.Oracle, we will need the copyrights adjusted for incubation to pass |
| | 315 | <jasonbirch> ? what are they now? |
| | 316 | <HarisK> Can we discuss little bit on posted Future stuff? |
| | 317 | <gregb> josonbirch: they are missing at this time |
| | 318 | <orest> FYI: Bob cut out due to losing their internet connection. Unfortunately, now he is in another meeting. |
| | 319 | <jasonbirch> Oh, that might be a problem :) |
| | 320 | <gregb> We can discuss futures |
| | 321 | <gregb> Where do you wish to start? |
| | 322 | <HarisK> FDO Client Utilities |
| | 323 | <HarisK> that name doesn't sound right to me |
| | 324 | <gregb> Orest has published a working paper |
| | 325 | <jasonbirch> Got to go... thanks! |
| | 326 | <gregb> A starter document |
| | 327 | |<-- jasonbirch has left irc.freenode.net ("ChatZilla 0.9.78.1 [Firefox 2.0.0.8/2007100816]") |
| | 328 | <HarisK> yes I haven't invested enough time into it |
| | 329 | <gregb> Orest, do you plan to update that doc? |
| | 330 | <RobertF> I think we should allow more time before we discuss futures. |
| | 331 | <orest> The idea is to start with some high level options and let folks add to it. |
| | 332 | * FrankW things futures is a bit much for this meeting too. |
| | 333 | <orest> I was going to wait for others to comment before adding more to it right now. |
| | 334 | <HarisK> yes ok, I redraw topic |
| | 335 | <HarisK> I will pst on mailling list |
| | 336 | * mloskot 's futures include postgis provider improvements and completing unit tests |
| | 337 | <FrankW> HarisK: sounds good! |
| | 338 | <gregb> ok |
| | 339 | <gregb> Are there other topics for today's meeting? |
| | 340 | <FrankW> WMS provider issue? |
| | 341 | <gregb> Yes |
| | 342 | <gregb> I posted a note to internals describing the issue |
| | 343 | <gregb> Is there any feedback? |
| | 344 | <FrankW> I'm ok with the proposed solution. |
| | 345 | <gregb> Orest? |
| | 346 | <gregb> Any other comments? |
| | 347 | <orest> I'm ok with it. |
| | 348 | <mloskot> I'm ok too |
| | 349 | <gregb> If not, I motion that RFC 10 be updated as proposed. |
| | 350 | <gregb> And implemented as stated |
| | 351 | <orest> Did anyone double check that the current version of the WMS provider will in fact skip over that new element? |
| | 352 | <gregb> No. I believe that has not been validated |
| | 353 | <gregb> I do not see a problem, but testing is required. |
| | 354 | <orest> I wouldn't mind getting it validated just to be sure. |
| | 355 | <gregb> Ok. Let's postpone the vote until that time |
| | 356 | <FrankW> ok |
| | 357 | <gregb> We can do it on fdo-internals |
| | 358 | <mloskot> ok |
| | 359 | <FrankW> ok |
| | 360 | <gregb> Are there any other topics for discussion? |
| | 361 | <mloskot> we've cleaned the meeting agenda |
| | 362 | <mloskot> I don't have any other topics myself. |
| | 363 | <gregb> If not, I propose we djourn |
| | 364 | <FrankW> +1 |
| | 365 | <gregb> +1 |
| | 366 | <mloskot> +1 |
| | 367 | <orest> +1 |
| | 368 | <RobertF> Since I can't vote...see you next time. |
| | 369 | <gregb> Thanks everyone. I will ensure we do these more regularly |
| | 370 | <HarisK> Greg +1, good job |
| | 371 | <mloskot> Thanks Greg! |
| | 372 | <HarisK> thanks |
| | 373 | <HarisK> bye |
| | 374 | <orest> Good meeting. Thanks everyone! |
| | 375 | <gregb> You are welcome. Bye |
| | 376 | <orest> Bye. |
| | 377 | }}} |
