[wiki:ProjectSteeringCommittee Project Steering Committee - Home] == Meeting Info == This meeting of the !MapGuide PSC takes place Thursday, May 6, 2010 at 18:00 UTC (2:00 PM ET / noon MT / 11:00 AM PT). Meeting Chair: Bob Bray Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=05&day=06&year=2010&hour=12&min=0&sec=0&p1=55 Location: The meeting will be held on IRC at [irc://irc.freenode.net/mapguide #mapguide] == Agenda == * Appoint a Meeting Secretary * !MapGuide 2.2 Beta Release (Trevor) * Move Maestro up a level in the subversion repository? (Tom) == Minutes == PSC Members present: Andy, Bob, Tom, Trevor === !MapGuide 2.2 Beta Release === * Meta tiling rfc ([http://trac.osgeo.org/mapguide/wiki/MapGuideRfc90 RFC 90]) code is not ready and will be marked "on hold" and will not be in 2.2. * Target May 14th for beta. * Documentation will be light. === Move Maestro up a level in the subversion repository? === * With the direction of Maestro, we should consider moving it up to the root of the MG vault. * Not enough members to make a decision. Will continue discussion on email. === Full transcript === {{{ ok first up is the MapGuide 2.2 Beta Release (Trevor) Yep. Just wanted to chat about RFC status. The meta tiling RFC seems to be on hold. According to Zac, UV is moving right now. Should we wait for it? Ask the list? other? I would defer it personally, what do others think? I am ok with defer. I can send an email to -internals suggesting it. I think we should defer it. Ok. That's all I had for the beta. I can do the builds at any time. Ok then let's do it. Can someone change the status of the RFC to "On Hold"? Sure. I will put it on hold. End of next week for the beta? The documentation might be a bit light (pretty busy right now). That's ok, as long as we can post the build and provide basic instructions - that's fine. Ok. Sounds good. Thanks. The only other item belongs to Tom - Move Maestro up a level in the subversion repository? (Tom) There was a discussion about moving the Maestro code up in the directory structure so that it could have it's own branching structure. I was originally against this, but after being told the direction of Maestro from Jason I have changed my mind. Jason wrote: "Although Maestro is linked to MapGuide, it is not a 1:1 relationship (unlike Studio), and has potential to be even less linked over time. Jackie has plans of pulling full FDO Toolbox capabilities into Maestro, I wouldn't be surprised to see support for GeoREST configuration / templating at some point, and who knows... maybe someone will make it create MapServer config files at... ...some point :) IMO, locking it into the MapGuide release cycle constrains its potential." It is currently at /Trunk/Tools/Maestro, but I think that we would like to move it to /Maestro. This would mean the root of our vault would be /trunk, /branches, /sandbox, /tags, /Maestro. And then /Maestro would have subdirectories trunk, branches. (I type fast eh :)) you cut and paste well Tom Yea that is ok with me too - anyone object? The other option is to make it, it's own project. But that requires a lot more work. I'm good with moving it Mr. cut and paste. Should we put it under Tools/Maestro or just /Maestro Unfortunately, I think that Jason is the one who objects, and he's not here I would go just /Maestro What's his objection? From an email: > >>> I think we discussed this when we were initially bringing Maestro in. > >>> > >>> It was a while back, but I think the intention was to just use a > >>> prefix for the Maestro branches (/branches/Maestro-2.1, etc...) > >>> similar to how its done in tags. I like having it as it's own top level folder personally. I think Apache follows similar semantics. ok - let's leave this on e-mail to resolve. I am ok with that approach too, we just need to collectively decide. Ok. Works for me too. OK THat was it for the agenda - any other business? (tom's really happy - short PSC meeting...) Me too, I am swamped. No, but I just saw a posting on mapguide-users that someone is happy with the HTTP API doc nice work Trevor! Nice work Trevor! dang - and I could have cut and paste if I waited one more second. Ok guys, then we are adjourned. Thanks! Thanks You're welcome and thanks everyone! }}}