| | 21 | |
| | 22 | == Minutes == |
| | 23 | |
| | 24 | PSC Members present: Jason, Bruce, Tom, Andy, Kenneth, Trevor. |
| | 25 | |
| | 26 | === The 2.1 Release === |
| | 27 | * The PSC should follow the posted release process http://mapguide.osgeo.org/releaseprocess.html |
| | 28 | * Additional Fusion work may still be required for the release. |
| | 29 | * Jason will release a MapGuide 2.1 beta based on Fusion trunk ASAP. The official release date is set for one month after the beta release. |
| | 30 | * Jason and Trevor will clean the existing Trac tickets. 1.2 tickets will be blanket closed with a note to reopen if necessary. Retesting against 2.1 will be requested for all tickets submitted against 2.0. |
| | 31 | |
| | 32 | === Sponsorship === |
| | 33 | * Trevor will send RFC83 out to -internals and -users for review and contact Frank Warmerdam for details on the OSGeo sponsorship program. |
| | 34 | |
| | 35 | === CCLA Forms === |
| | 36 | * Tom will collaborate with Bob to create a Corporate Contributor License Agreement based on the existing Fdo agreement. |
| | 37 | |
| | 38 | === Progress on the nightly builds === |
| | 39 | * Trevor will migrate the existing build VMs to VMware based virtualization. Once the move is complete, work will continue on integrating the installers into the nightly build process. A link to the nightly builds will be posted on the !MapGuide website once this has been completed. |
| | 40 | |
| | 41 | === RFC 69 Funding/Resources === |
| | 42 | * Since RFC 69 depends on Fdo RFC 40, work on this RFC will be delaying until the underlying Fdo functionality can be implemented. |
| | 43 | |
| | 44 | === End of meeting === |
| | 45 | |
| | 46 | == Full transcript == |
| | 47 | {{{ |
| | 48 | |
| | 49 | Start of #mapguide buffer: Thu Sep 10 13:45:49 2009 |
| | 50 | * Now talking in #mapguide |
| | 51 | * Topic is 'MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs: |
| | 52 | http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/proje |
| | 53 | cts/4656 -and- http://cia.navi.cx/stats/project/MapGuide' |
| | 54 | * Set by jasonbirch on Mon May 28 12:47:53 |
| | 55 | * bdechant (n=chatzill@ussclout1.autodesk.com) has joined #mapguide |
| | 56 | * jasonbirch (n=jasonbir@osgeo/member/jasonbirch) has joined #mapguide |
| | 57 | * amorsell (n=chatzill@76.178.132.188) has joined #mapguide |
| | 58 | * tomf2 (n=tomf2@ussclout1.autodesk.com) has joined #mapguide |
| | 59 | <jasonbirch> Are we meeting now? Or did something else happen that i'm oblivious to? :) |
| | 60 | * jasonbirch is still in vacation catchup mode |
| | 61 | * amorsell (n=chatzill@76.178.132.188) Quit (Remote closed the connection) |
| | 62 | <trevorw> Hi Jason, I think we are meeting. Haris also accepted the meeting invite so |
| | 63 | hopefully he will be able to join. |
| | 64 | * tomf2 (n=tomf2@ussclout1.autodesk.com) Quit (Read error: 54 (Connection reset by peer)) |
| | 65 | * amorsell (n=chatzill@76.178.132.188) has joined #mapguide |
| | 66 | <trevorw> I don't know about Bob and Paul though. |
| | 67 | <bdechant> Tom is coming back - had to reboot his laptop |
| | 68 | <trevorw> I think Bob wanted Tom to chair the meeting from last week since he couldn't |
| | 69 | make it. |
| | 70 | <bdechant> That might still be the plan |
| | 71 | <trevorw> Hey Bruce, what happened to Tom? Looks like his connection got turfed. |
| | 72 | <bdechant> Look up a few comments :) |
| | 73 | <jasonbirch> While we're here, if you're in Canada and wanting to travel before Dec 17, |
| | 74 | book today with WestJet :) http://www.redflagdeals.com/deals/main.php/alldeals/comment |
| | 75 | s/westjetcom_up_to_65_off_fall_travel_ends_september_10/ |
| | 76 | <trevorw> Hmm... maybe I should increase my font size :) |
| | 77 | <bdechant> :) |
| | 78 | * kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) Quit (Read error: 110 (Connection |
| | 79 | timed out)) |
| | 80 | <trevorw> I just checked the PSC page. Looks like we need 2/3rds for quorum (6 people) if |
| | 81 | we want to vote on anything. |
| | 82 | <bdechant> Correct |
| | 83 | <bdechant> I can chair this meeting if no one objects |
| | 84 | * tomf2 (n=tomf2@132.188.64.150) has joined #mapguide |
| | 85 | <tomf2> rebooted! |
| | 86 | <bdechant> Should we get started? |
| | 87 | <trevorw> Yes. Let's get started. |
| | 88 | * kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide |
| | 89 | <bdechant> Ok - 1st agenda item is to appoint a meeting secretary |
| | 90 | <bdechant> Any volunteers? |
| | 91 | <trevorw> I can if no one has prior experience. Not sure if I can cut and paste from my |
| | 92 | chat client... |
| | 93 | <bdechant> Most of us have had a turn |
| | 94 | <bdechant> But thanks for volunteering Trevor :) |
| | 95 | <bdechant> If you cannot cut/paste let me know and I can email the notes to you |
| | 96 | <trevorw> Ok. I'm good. Looks like I can save the session to a file. |
| | 97 | <bdechant> Next item on the list - the 2.1 Release |
| | 98 | <bdechant> So what are we doing and when? |
| | 99 | <kenneth_> I propose that we describe a formal release process to prevent lags like this |
| | 100 | in the future |
| | 101 | <kenneth_> From what I can see, the OpenLayers team seems to have a very nice process |
| | 102 | <bdechant> agreed - Kenneth would you like to write that up and post it on our wiki? |
| | 103 | <kenneth_> Basically, a release manager is appointed at the time a branch is made |
| | 104 | <tomf2> Is it different than http://mapguide.osgeo.org/releaseprocess.html |
| | 105 | <kenneth_> No, it looks similar |
| | 106 | <tomf2> OK, we've had that from the start, looks like we're just not following it |
| | 107 | <bdechant> The problem is that we haven't been following it |
| | 108 | <bdechant> Do we have an official Release Manager? |
| | 109 | <trevorw> The posted release process we have seems reasonable. I think part of the |
| | 110 | problem is limited resources to back the release process - release manager and |
| | 111 | developers to fix critical defects. |
| | 112 | <trevorw> I believe Jason has been unoffically standing in as release manager this time |
| | 113 | around. |
| | 114 | <tomf2> Yes, resources are a problem, Autodesk used to do all this before, but those |
| | 115 | resources are no longer available to us |
| | 116 | <kenneth_> A thing that seems to be missing is the "pullup" state for tickets, which |
| | 117 | developers can set when a ticket has a reasonable solution, and the release manager |
| | 118 | should pull it into the release branch |
| | 119 | <kenneth_> That makes the RM's job much easier |
| | 120 | <trevorw> So ticket fixes are submitted as patches or to a sandbox? Then someone has the |
| | 121 | merge the fix into the release (candidate) branch? |
| | 122 | <kenneth_> yes, or to trunk, but only the RM commits to the release branch |
| | 123 | <tomf2> Is that is what is holding up the 2.1 release right now though? |
| | 124 | <bdechant> That seems like a lot of work for the RM |
| | 125 | <kenneth_> ok, I thinks its less work, just look at the list of open issues for the |
| | 126 | release, follow up on anything that is missing a pullup tag, and merge the |
| | 127 | patches/revisions for those marked for pullup |
| | 128 | <trevorw> Yes. It's a ton of work for the RM. I think developers should be doing |
| | 129 | approved submissions to 2.1. They know what the fix is. The RM should be giving |
| | 130 | approval and figuring out what has to go in. |
| | 131 | <kenneth_> its not a showstopper for me, just a suggestion, that seems to work really well |
| | 132 | for OL |
| | 133 | <trevorw> So how do we tag these pullup tickets? I'm not sure the milestone and version |
| | 134 | fields in trac are sufficent. |
| | 135 | <trevorw> Do we need some sort of nomination/approval field? |
| | 136 | <kenneth_> in the status field, where you have assigned, fixed, reopend, etc. |
| | 137 | <kenneth_> afaik, there is no nomination/approval in OL trac |
| | 138 | <kenneth_> the RM decides what fixes are good enough to make it into the release, and what |
| | 139 | issues are holding it back |
| | 140 | <kenneth_> pullup simply states that the ticket is fixed and reviewed, and that the |
| | 141 | developers consider it ready for inclusion |
| | 142 | <tomf2> Sorry, but can we move on. I have some questions: What are we waiting for for the |
| | 143 | next beta? About when are we targeting for 2.1? |
| | 144 | <jasonbirch> Right now, just waiting for a Fusion that works. |
| | 145 | <jasonbirch> Where works = something that doesn't entirely piss off everyone. |
| | 146 | <kenneth_> perhaps the first item on the agenda should be two: How does 2.1 get released |
| | 147 | ASAP, and how do we prevent future delays |
| | 148 | <jasonbirch> From my perspective, the main problem has been a lack of resources to get |
| | 149 | showstopper bugs fixed. |
| | 150 | <jasonbirch> I can rev betas as often as required, but no point if things aren't getting |
| | 151 | fixed. |
| | 152 | <tomf2> How can we get things fixed? Any ideas? |
| | 153 | <kenneth_> considering that Fusion has it's own release cycle, shoud we consider not |
| | 154 | including fusion (or just 1.1) in the 2.1 release? |
| | 155 | <trevorw> Is there a list of showstopper issues published somewhere that we can track |
| | 156 | against? That might be what we are missing. |
| | 157 | <jasonbirch> Perhaps we need tighter management of the Trac issues list. |
| | 158 | <jasonbirch> Right now priorities are set by the submitter, and not really managed. |
| | 159 | <jasonbirch> Well, not rigorously, anyway. |
| | 160 | <trevorw> Exactly. Trac doesn't tell us what we have to fix. Maintaining the must fix |
| | 161 | list should be the RM's and PSC's job. |
| | 162 | <jasonbirch> Personally, I think part of the problem is that Trac is basically a |
| | 163 | duplication of effort for ADSK |
| | 164 | <jasonbirch> So we are left with confusion, no resources to manage, etc. |
| | 165 | <kenneth_> would that make more people angry than further delaying the 2.1 release? |
| | 166 | * kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) Quit (Remote closed the connection) |
| | 167 | <jasonbirch> Trac _could_tell us that. |
| | 168 | <jasonbirch> But it's hard for a non-technical manager to go back and reclassify existing |
| | 169 | tickets, clean them up, etc. |
| | 170 | <tomf2> I'm confused, what does Autodesk have to do with resources for fixing Fusion |
| | 171 | defects? |
| | 172 | * kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide |
| | 173 | <jasonbirch> Nothing Tom, I'm talking about release process ni general. |
| | 174 | <tomf2> Oh, OK |
| | 175 | <jasonbirch> I'd be against releasing MapGuide without Fusion. |
| | 176 | <jasonbirch> I'd be OK releasing it with current Fusion trunk though. |
| | 177 | <tomf2> ...but the current Fusion trunk has too many problems? |
| | 178 | <trevorw> Should we just create a page with the targeted 2.1 defects on the Trac website, |
| | 179 | or can we mark the tickets somehow and run a query? |
| | 180 | <jasonbirch> Especially if Fusion can't devote time to pushing a 2.x release. |
| | 181 | <jasonbirch> We can mark the tickets, and I can build a custom query if required. |
| | 182 | <jasonbirch> And then automatically bring these into a Wiki page. |
| | 183 | <jasonbirch> But really, it's just a matter of setting the milestone. I think. |
| | 184 | <trevorw> That would be good. And if we create a corresponding MapGuide ticket for the |
| | 185 | required Fusion tickets and URL link them, it should give us some more clarity. |
| | 186 | <jasonbirch> That makes sense, and a link back from Fusion asking to update on completion. |
| | 187 | <bdechant> That would be nice |
| | 188 | <jasonbirch> I think a cleanup of the MapGuide trac is most important though. |
| | 189 | <trevorw> Just setting the milestone might lead to too much noise unless someone bumps the |
| | 190 | milestone to 2.2 for all the stuff we are not fixing for the release. That would be |
| | 191 | "cleanup". |
| | 192 | <jasonbirch> I can go and close a lot of old issues, asking for re-open if still WIP / |
| | 193 | outstanding. |
| | 194 | <jasonbirch> Items should not have a milestone at all unless they are accepted and there |
| | 195 | are resources assigned. |
| | 196 | <bdechant> That would be great Jason - as the tickets need a cleaning |
| | 197 | <trevorw> I can also help Jason with the cleaning. |
| | 198 | <bdechant> Can we assign an action item to you Jason/Trevor for cleaning up the tickets? |
| | 199 | <jasonbirch> I'm was just going to blanket close all issues that are reported at version |
| | 200 | 1.2 (with a note to re-open if still an issue), and ask for retests against 2.1 for |
| | 201 | items submitted at 2.0. |
| | 202 | <jasonbirch> Sure. |
| | 203 | <bdechant> Thanks |
| | 204 | <bdechant> That makes sense Jason |
| | 205 | <jasonbirch> I'm also going to clear the milestone from all tickets, unless they are |
| | 206 | accepted by someone. |
| | 207 | <bdechant> Is there anyway that we could have that field only controllable by the PSC/RM? |
| | 208 | <jasonbirch> I don't think so, but not sure how granular Trac permissions are. |
| | 209 | <trevorw> This sounds good. If we cannot control the milestone field, then maybe we add |
| | 210 | an approved for release field? |
| | 211 | <bdechant> Having both might be confusing |
| | 212 | <trevorw> Maybe we change milestone to approved for? |
| | 213 | <trevorw> But milestone could mean "targeted for". So maybe we need "target for" and |
| | 214 | "approved for"? |
| | 215 | <trevorw> Developers set targeted for, psc sets approved for? |
| | 216 | <bdechant> That makes more sense |
| | 217 | <trevorw> Tickets against approved RFCs can set both since approval has already been given. |
| | 218 | <jasonbirch> I don't think Trac is that flexible... |
| | 219 | <jasonbirch> At least not through the web admin. |
| | 220 | <trevorw> This would all be a manual process, assuming we can change "milestone" to |
| | 221 | "targeted for". |
| | 222 | <trevorw> Developers would have to be good and follow the process. |
| | 223 | <jasonbirch> Can't. Milestone, Version, etc are built-in concepts in Trac. |
| | 224 | <jasonbirch> But milestone == approved for. |
| | 225 | <jasonbirch> Developers are supposed to control acceptance of work. |
| | 226 | <jasonbirch> Once it's accepted, should be done in trunk. |
| | 227 | <jasonbirch> If there's a branch, need approval to apply to that. |
| | 228 | <jasonbirch> Probably just done via mailing list? |
| | 229 | <trevorw> Do we need a "trunk" milestone then? |
| | 230 | <trevorw> And two separate tickets logged? |
| | 231 | <trevorw> Currently, one ticket applies to both streams. |
| | 232 | <jasonbirch> I think we're mixing concepts. |
| | 233 | <CIA-28> MapGuide: waltweltonlair * r4215 /trunk/MgDev/Common/Renderers/DWFRenderer.cpp: |
| | 234 | (log message trimmed) |
| | 235 | <CIA-28> MapGuide: Fix #1088: Plot to DWF (eplot) - plot incomplete / features missing |
| | 236 | <CIA-28> MapGuide: The bug is in DWFRenderer. It generates a W2D resource for each layer |
| | 237 | in the |
| | 238 | <CIA-28> MapGuide: map. There's some optimization code to only generate certain opcodes |
| | 239 | when style |
| | 240 | <CIA-28> MapGuide: information changes from feature to feature. This works fine if you |
| | 241 | just have |
| | 242 | <CIA-28> MapGuide: one layer: the required opcodes are added as part of the first feature |
| | 243 | and are |
| | 244 | <CIA-28> MapGuide: updated as necessary for the layer's remaining features. But if you |
| | 245 | have more |
| | 246 | <jasonbirch> Issues are fixed in trunk. Once there's a code freeze, issues can only be |
| | 247 | pulled up to branch on approval from RM. |
| | 248 | <trevorw> That sounds right. How do we get Trac to "track" the approval? |
| | 249 | <trevorw> Does trunk have no milestone, then PSC sets milestone? |
| | 250 | <jasonbirch> For work in process, the milestone would be set to next release. After code |
| | 251 | freeze, only RM can set milestone to branched verison? |
| | 252 | <jasonbirch> (current release) |
| | 253 | <CIA-28> MapGuide: waltweltonlair * r4216 /trunk/MgDev/Common/Renderers/DWFRenderer.cpp: |
| | 254 | Fix comment typo |
| | 255 | <jasonbirch> Anyway, to move on, how about I post an official Beta using Fusion trunk. |
| | 256 | <jasonbirch> Give that a month, and then release 2.1 with whatever the current state is? |
| | 257 | <trevorw> That sounds reasonable to me. |
| | 258 | <bdechant> Sounds good |
| | 259 | <jasonbirch> I don't think there are any core show-stoppers in MapGuide, unless you need |
| | 260 | to run with fdo connection caching turned on. :) |
| | 261 | <kenneth_> Fine by me |
| | 262 | <jasonbirch> I'll try to get that done this weekend. |
| | 263 | <bdechant> Ok - so can we move on to the next agenda item? |
| | 264 | <tomf2> +1 |
| | 265 | <jasonbirch> Yes. |
| | 266 | <tomf2> ...to Jason's proposal |
| | 267 | <tomf2> ...and to moving on :) |
| | 268 | <bdechant> Next item - Sponsorship RFC83 |
| | 269 | <tomf2> We're over time |
| | 270 | <jasonbirch> I may have to leave soon, but I'm OK with vote on RFC83 as it stands. |
| | 271 | <bdechant> Should we vote on RFC83 and then wrap it up? |
| | 272 | <tomf2> me too, but was it put out for review? |
| | 273 | <jasonbirch> Would need to define process for approving funds expenditure, and appoint |
| | 274 | someone to track and report to OSGeo |
| | 275 | <jasonbirch> I think it was circulated informally. |
| | 276 | <bdechant> Ahh right - not offically reviewed yet |
| | 277 | <trevorw> It was circulated internally but do we need to get community feedback on it? |
| | 278 | <tomf2> yes |
| | 279 | <bdechant> They need to be invovled |
| | 280 | <jasonbirch> All comms should be via -internals list unless there is a specific reason not |
| | 281 | to. |
| | 282 | <jasonbirch> But, perhaps copy -users on this one too. |
| | 283 | <trevorw> Ok. I will put it out for review. Do we want to include a funding target in |
| | 284 | the RFC? 50k, 100k, 200k? |
| | 285 | <trevorw> I can check with Frank W on the details for the OSGeo sponsorship mechanism |
| | 286 | <CIA-28> MapGuide: NormOlsen * r4217 /trunk/MgDev/Common/ (11 files in 2 dirs): |
| | 287 | <CIA-28> MapGuide: This submission can be considered the first complete beta submission |
| | 288 | for RFC 76. |
| | 289 | <CIA-28> MapGuide: It includes all (most all anyway) functionality originally intended by |
| | 290 | the RFC, |
| | 291 | <CIA-28> MapGuide: and most all functionality has been tested, superficially, in a rather |
| | 292 | sterile |
| | 293 | <CIA-28> MapGuide: environment using only the debugger to manually inspect numerical |
| | 294 | results. |
| | 295 | <CIA-28> MapGuide: Surely, once a real application produces graphical results we will have |
| | 296 | some |
| | 297 | <CIA-28> MapGuide: bugs to fix. |
| | 298 | <bdechant> ok - so RFC83 will be posted for review |
| | 299 | <jasonbirch> How about we hold off on target until we see what kind of response we get? |
| | 300 | <bdechant> Do we want to stop here as we are out of time? |
| | 301 | <bdechant> I would leave target out |
| | 302 | <trevorw> Ok. Sounds good. The RFC should generate some list traffic. Target is out. |
| | 303 | <jasonbirch> If someone can take a task to look into CCLA forms? |
| | 304 | <jasonbirch> There was one developed in Doc format, and it used to be online,but I can't |
| | 305 | find it now. |
| | 306 | <jasonbirch> And there is no way for employers to grant code submission rights as it |
| | 307 | stands. |
| | 308 | <jasonbirch> A bit problematic. |
| | 309 | <bdechant> Indeed |
| | 310 | <kenneth_> I posted the CCLA thing, and basically I would like to know how I can get a |
| | 311 | CCLA. I have done work that I had to scrap because I could not get one. |
| | 312 | <kenneth_> And I won't ask my employer to do MapGuide work before I can guarantee that it |
| | 313 | will can be legally submitted |
| | 314 | <kenneth_> I have searched the website, and asked on the mailing list, but no response, so |
| | 315 | I assume that it never existed, or has gone missing |
| | 316 | <tomf2> Never had one for MapGuide |
| | 317 | <tomf2> I'm wondering what is going on here at Autodesk now, we all have individual CLAs |
| | 318 | <trevorw> I think we were using the standard OSGeo contributor agreement. I only see the |
| | 319 | proposal for it posted. http://wiki.osgeo.org/wiki/Individual_Contributor_License_Agree |
| | 320 | ment_%28CLA%29 |
| | 321 | <trevorw> Google... http://fdo.osgeo.org/files/Individual%20Contributor%20Agreement%20-%20 |
| | 322 | FDO.pdf |
| | 323 | <trevorw> Now where's the MapGuide one? |
| | 324 | <tomf2> kenneth_ are you saying that the individual CLA is not good enough legally, or is |
| | 325 | it something that your employer requires? Either way, we should get the CCLA out; I'll |
| | 326 | see if Bob can help me (or I can help him) with that. |
| | 327 | <jasonbirch> We can steal FDO's |
| | 328 | <jasonbirch> And their process for submitting, etc. |
| | 329 | <kenneth_> It states that the individual has employers consent. That is a bit odd because |
| | 330 | I signed mine with regards to the work I had done personally |
| | 331 | <tomf2> jasonbirch: what process for submitting? |
| | 332 | <kenneth_> tomf2 I would like some signed document from my employer granting me rights to |
| | 333 | commit work that belongs to him |
| | 334 | <kenneth_> I expected that that was what a CCLA is |
| | 335 | <kenneth_> that the company accepts that employees submit code to the project |
| | 336 | <jasonbirch> Yes, that was the intent. |
| | 337 | <tomf2> Here's the FDO one: http://fdo.osgeo.org/files/Corporate%20Contributor%20Agreement |
| | 338 | %20-%20FDO.pdf |
| | 339 | <trevorw> I found the one I signed - stock OSGeo agreement - http://mapguide.osgeo.org/fil |
| | 340 | es/Individual%20Contributor%20Agreement.pdf |
| | 341 | <trevorw> Bob would probably know for certain but I don't know if the Corporate agreement |
| | 342 | was every approved. |
| | 343 | <tomf2> I believe it is more "the project will accept code from the designated employees |
| | 344 | of that company" |
| | 345 | <kenneth_> The FDO one looks just right, can Tom or Bob post one for MG? |
| | 346 | <trevorw> I think the stock OSGeo agreement and the Fdo agreement are basically the same. |
| | 347 | Just replace OSGeo with Fdo |
| | 348 | <tomf2> I have to go |
| | 349 | <trevorw> Just to confuse the issue even more, Fdo has posted a corporate contributor |
| | 350 | agreement as well http://fdo.osgeo.org/files/Corporate%20Contributor%20Agreement%20-%20F |
| | 351 | DO.pdf |
| | 352 | * kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) Quit (Remote closed the connection) |
| | 353 | <trevorw> Ok. Are we done for the day? |
| | 354 | * kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide |
| | 355 | <tomf2> trevorw see my third from last message |
| | 356 | <jasonbirch> I have to go :) |
| | 357 | <trevorw> Oops. Sorry Tom. Didn't catch the corporate. |
| | 358 | <jasonbirch> Basically, CCLA was required, but also needed individuals. |
| | 359 | <jasonbirch> Gotta find that doc now... |
| | 360 | <jasonbirch> http://lists.osgeo.org/pipermail/fdo-internals/2007-November/001589.html |
| | 361 | <jasonbirch> Not sure if that's all... |
| | 362 | <trevorw> Ok. I have three action items listed for the meeting: |
| | 363 | <trevorw> 1. Jason/Trevor Clean trac tickets |
| | 364 | <trevorw> 2. Jason release beta based on fusion trunk follow by 2.1 release 1 month later |
| | 365 | <trevorw> 3. Trevor post RFC 83 for review to -internals and -users. Talk to Frank W |
| | 366 | about OSGeo sponsorship mechanism |
| | 367 | <jasonbirch> Could Tom / Bob look into porting FDO CCLA to MapGuide? |
| | 368 | <trevorw> Both corporate and individual variants? |
| | 369 | <jasonbirch> We already have an individual CLA I think. |
| | 370 | <tomf2> And I've already said that I would do that? Trevor do you have a filter on my |
| | 371 | messages! :) |
| | 372 | <trevorw> Ok. Just corporate then. The individual agreement does not mention Mapguide |
| | 373 | but that's probably ok. |
| | 374 | <jasonbirch> Oh, me too :) |
| | 375 | <kenneth_> The last item on the list (RFC #69) should probably be delayed, as it currently |
| | 376 | depends on FDO RFC #40, unless it should be answered as a prototype question |
| | 377 | <kenneth_> trevorw: what is the status for the nightly builds? |
| | 378 | <trevorw> For the builds, I would like to migrate the Xen VMs to VMware. I am planning on |
| | 379 | moving to a colocation site to do official VMware hosting and would like to use the same |
| | 380 | infrastructure. This would also enable me to host a code collaboration tool. Didn't |
| | 381 | want to do that one out of my basement. |
| | 382 | <bdechant> Sorry had to step out for a meeting |
| | 383 | <bdechant> Back now |
| | 384 | <trevorw> The builds machines are still there, but the installers have not been integrated |
| | 385 | into the build process yet. |
| | 386 | <kenneth_> Ok, so what would be the plan for getting a link to a nightly build posted on |
| | 387 | the osgeo websited? |
| | 388 | <kenneth_> first move to VMWare, then move hosting systems, then integrate installers, |
| | 389 | then post link? |
| | 390 | <trevorw> Yep. That's about right. For the beta, Jason has been doing the builds himself. |
| | 391 | <trevorw> Do we want a builds link up sooner than that? The colocation will probably not |
| | 392 | happy until the end of the month. |
| | 393 | <trevorw> I could move the VMs over and continue hosting out of my basement temporarily. |
| | 394 | Download bandwidth would be slow though. |
| | 395 | <kenneth_> The beta is more important to me than the nightly builds, I just wanted some |
| | 396 | kind of assurance that the builds are progressing |
| | 397 | <trevorw> Having nightly builds available during the beta period might be useful. |
| | 398 | <trevorw> Yes. The builds are progressing. I have been busy with "groundwork" the last |
| | 399 | few weeks - colocation negotiations and VMware certification. |
| | 400 | <kenneth_> super |
| | 401 | <kenneth_> does that conclude the psc meeting? |
| | 402 | <bdechant> thanks |
| | 403 | <trevorw> Yep. I will add another action item for the builds. Thanks everyone |
| | 404 | <bdechant> I think that is it |
| | 405 | <bdechant> Thanks all |
| | 406 | End of #mapguide buffer Thu Sep 10 13:45:49 2009 |
| | 407 | |
| | 408 | }}} |
