Version 3 (modified by 17 years ago) ( diff ) | ,
---|
Project Steering Committee - Home
Meeting Info
The fifteenth meeting of the MapGuide PSC will take place Thursday December 6th at 17:00 UTC (1:00 PM ET / 11:00 AM MT / 10:00 AM PT).
Meeting Chair: Bob Bray
Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=12&day=6&year=2007&hour=11&min=0&sec=0&p1=55
Location: The meeting will be held on IRC at #mapguide
Agenda
- MapGuide Open Source 2.0 Beta 2
- Availability of MGOS 2.0 Beta Test Servers
- Enabling Subversion Post Commit Hooks
- Other Business?
Transcript
<rbray> Ok, sorry about that. I am ready to start. <rbray> Tom can you give us an update on the Beta. <tomf1> Yes <tomf1> We are upgrading the MGOS isntalls to the latest FDO beta posted on osgeo.org <tomf1> We should have new installs available for next week. It will also have GDAL 1.4.4 compliant FDO provider <tomf1> so ECW and MrSID support will be back <tomf1> So beta 2 early next week <tomf1> That's it. <rbray> Where are we with bugs. <tomf1> Oh, some more of the documentation should come back online too, as I get around to that. <rbray> Will it also include a new fusion drop, with some bug fixes / enhancements? <tomf1> It will include bug fixes in all aspects of the product. <tomf1> I'll try to set up a trac query that has the list of fixed tickets between the two builds. I don't have that right now <rbray> Anyone have any concerns? Any specific items that need to be addressed for Beta 2 beyond what Tom mentioned? <geojason> There were some installer issues... <geojason> like adding the json mime type properly, and... <geojason> Not allowing an install on the same machine as 1.2 <geojason> Any chance these can be remedied? <geojason> the json thing was just for IIS6/Win2k3 <tomf1> We are working on the mime type issue <tomf1> There is nothing being done about side-by-side install capabilities of MGOS <geojason> Even if the installer completed and the user had to change the ports, it would be better than seeing it as "same product" and halting the install. <tomf1> That's good to know <rbray> Yea I agree with that. <rbray> They will run side by side fine with some tweaking. Let them tweak. <geojason> The user has to be savvy enough to pass an alternate install path to the installer in the first place :) <tomf1> I'll talk to Tim about that. No guarantees though <geojason> k :) <rbray> Other issues or concerns going into Beta2? <rbray> OK. <tomf1> One sec <rbray> holding <tomf1> Were there plans before about doing builds on a OSGeo server? <tomf1> What happened with that? <rbray> Dunno. I think that is still waiting for some brave soul to adopt it. <geojason> We can still do it... <geojason> Just have to get some time from Mat :) <rbray> I do not want to hold up Beta or RCs for that though. <geojason> Oh, and some commandline build scripts would help. <geojason> No, no kidding. <tomf1> OK, just thinking that that might be a way we could get stuff that we want into the installer as well. <tomf1> Done <rbray> OK <geojason> Yes, I have plans to look at NSIS when I have a second. or three-hundred. It looks easy. :) <rbray> Beta Test Servers. <geojason> Really hard to get it to do everything the InstallShield installer does, but maybe good enough. <rbray> We have the infrastructrue to host these, but probably not the bandwidth to keep them running. <rbray> Any volunteers willing to help? <rbray> Wow, don't everyone jump at once. <geojason> bandwidth? <Andy_Morsell> I can probably help, but am somewhat bandwidth challenged lately myself. <rbray> People time. <geojason> oh, sorry. I'm hardware-centric today. <geojason> What does that entail? Rolling back the VMWare image once in a while? :) <rbray> I think all we need is a small group to each pitch in a little here and there. Not a big commitment. <geojason> I'm game... <geojason> Are these Linux or Windows? <rbray> I'd like one more. <geojason> And.. are they VM? <rbray> They are VM's and Windows. <geojason> Will we have access to the root vm console to roll back if necessary? <HarisK> I am not sure what it means but I am willing to be in <geojason> Hey, HarisK ! welcome, I didn't see you there. <rbray> HarisK: Thanks. Just monitoring, restarting them, stuff like that. <HarisK> Hi :) <geojason> We can probably set up some kind of automated monitoring that restarts the services if they're dead... <HarisK> ok I am in <rbray> Yes we can. OK Tom and I will have Trevor get in touch with you directly. He will be setting this up. <rbray> At this point, I suggest we tackle this for Beta 2. <HarisK> ok <geojason> What kind of access are we going to allow? <rbray> FTP to upload data and php code. <rbray> Studio access for authoring. <rbray> They can basically use it like a hosted MG server. <geojason> The PHP code thing scares the shit out of me... <geojason> Good way to own the server. <rbray> But only for a limited tme, and no up time guarantees. <rbray> Yea <rbray> We could pull that part. <rbray> Up to you, Trevor, and Haris. <geojason> What's the alternative... only giving that level of access to "trusted" users? <geojason> Setting up new sites for users (not really interested in that...) <rbray> Well that is all we'll be giving. They will have to ask to use it and we will grant them access user by user. <rbray> We cannot open it to the world. That would be asking for trouble. <bdechant> yup - trusted users only :) <geojason> works for me... though it will be a lower level of "trust" than I usually apply for server access :) <rbray> Yes. It is really just a testbed. We do not want to get carried away or it will become a management nightmare. <rbray> I personally think it will be really cool. I do not know of another open geospatial project that does this. <rbray> OK next topic <rbray> Anyone object to enabling SVN post commit hooks? <tomf1> Not me <bdechant> nope <rbray> They allow for putting in something like fixed: #123 <mapguidetrac> Ticket #123: Cannot find overload for MgMappingService::GeneratePlot(), http://trac.osgeo.org/mapguide/ticket/123 <rbray> And that bug is automatically marked as fixed. <tomf1> I would also like to get it enforced that all submissions much be associated with a ticket <rbray> That would requrie the pre-commit hook. <geojason> As long as people stop putting things like RFC #23 :) <mapguidetrac> Ticket #23: Add icon on toolbar to show that map is reloading, http://trac.osgeo.org/mapguide/ticket/23 <geojason> Will it add comments to the ticket as the submissions are made? -->| wekeltr (n=chatzill@…) has joined #MapGuide <rbray> Yes. <geojason> That's useful. <rbray> Yea the comments from the submission get logged in trac. <rbray> It's just another level of integration. <geojason> Yes, I've found a few times where I wanted to look at what was fixed, and had to root through. <rbray> What do folks think about pre-commit hook. Requirenig a ticket to submit? <bdechant> Not sure I like that as some times the commit might be to fix a simple typo or source comment <tomf1> If we don't geojason is still going to have to "root through" <rbray> You can always refer to the original ticket. <bdechant> Lots of times there is no root ticket to reference <rbray> in the subsequent fixing submission. <rbray> Then there should have been. <bdechant> I can see a "catch all" ticket being created and commiters using that <rbray> Yuch <geojason> Those would get pretty big... <rbray> That would be bad <tomf1> I don't think that will be bad <tomf1> if the ticket says "typo and code comment updates" <geojason> One per release? <tomf1> It would be bad if the ticket summary was "stuff" <bdechant> or "Tab fixes" :) <geojason> heh <rbray> right, my concern is the general catchall. Hey ma, look I just submitted 2000 lines of code under tab fixes. <rbray> And its all new <rbray> Then we are wasting our tme <bdechant> hehe - I don't want to see that either <rbray> I personally support the idea, but it has to be properly used. <tomf1> I think we need the pre commit hook to make sure that submission/ticket associations are good, otherwise it's very easy to forget to reference the ticket in a submission <geojason> Wow, this is a cool bug: http://www.nabble.com/Problem-in-the-GenerateFilter%28%29-method-of-the-MgSelection-class-tf4937455.html#a14132755 =-= wekeltr is now known as trevorw <rbray> Nice one. Even gave code to re-produce. <rbray> So let's vote here. <rbray> First Motion: Enable Post Commit Hooks <rbray> I am +1 <geojason> +1 <HarisK> +1 <tomf1> +1Any other dissenters to the <Andy_Morsell> +1 <tomf1> oops, half typed message <bdechant> +1 <tomf1> ignore it please <geojason> dissenters will be shot :) <rbray> Good enough for me, passed. <rbray> Second Motion: Enable Pre-Commit Hooks implying all submissions require a ticket. <tomf1> 1 <tomf1> +1 <rbray> I am also +1, but Tom will need to document some process :) <geojason> +1 <bdechant> +1 (as long as we have a process) <HarisK> +1 <tomf1> Whatever we used when we were with collabnet was fine <tomf1> Where's the documentation for that? <rbray> Yes that is one that that worked well in the collabnet environment. <tomf1> Saves me from having to write it again :-) <rbray> There was none. <geojason> lol <rbray> OK. That is also good enough for me. <rbray> passed <rbray> I will send out the meeting minutes and as long as our absent member does not complain I'll ask SAC to enable them. <rbray> Any other business for today. <rbray> Apparently the website is a bit of a mess, but Jason is working on it. <rbray> :) <geojason> I'm just pushing... don't hav eserver access. <geojason> Hey, bob, you should be in there fixing it :) <rbray> Yea, well....I am a little pre-occupied today. I can do it this evening though. <tomf1> I found a broken link just a second ago for the official PSC page <tomf1> do we still have one, the one that was pointed to was http://mapguide.osgeo.org/psc.html <rbray> Send me stuff you see broken and I will try to fix. <geojason> All of the old URLs, especially if hardcoded, will break for now. <tomf1> ...from out wiki page http://wiki.osgeo.org/index.php/MapGuide_Open_Source <rbray> I know about those <geojason> Don't "fix" to point to ?q= pages... <rbray> No I wont <rbray> Any other business? <geojason> Updating the roadmap? <geojason> A few folks have asked. <geojason> And the one in Trac is out of date. <rbray> Tom and I can take a stab at that, and then ask the PSC for input. Does that seem like a reasonable approach. <rbray> We'll do it by updating Trac. <trevorw> Hi everyone, Tom asked me to join but I didn't have an IRC client installed. Haris, should I contact you at your sl-king email address? <HarisK> yes, please <geojason> Works for me rbray <rbray> OK, Tom let's see if we can find an hour for that tomorrow. |<-- CIA-17 has left irc.freenode.net (Client Quit) <HarisK> for this support do I need to be the one, or it can also be Simon from my company ? <trevorw> Ok. Thanks. Jason, should I use your nanaimo address? <rbray> Other agenda items or concerns? <rbray> Simon is fine. <geojason> Sure... <rbray> Just give his e-mail to Trevor. <HarisK> yes <geojason> Though after-hours probably better to use my home address: jason at jasonbirch.com <rbray> Asking again since we were side-tracked - Other agenda items or concerns? <geojason> The list of tickets is pretty long... <geojason> And assignment in Trac doesn't seem to be getting used much. <geojason> Is your internal system primary? <rbray> Yes. One of those things we are having a hard time reconciling. <rbray> Our internal system is all conected to product support and such. <geojason> Almost need some kind of gateway... but there would be a lot of risk there. <rbray> Yes and they are so completely incompatible it is not funny. <rbray> Tons of work to try and link <geojason> If I understood the internals better (ie, was a developer) I wouldn't mind managing the public tickets <geojason> But as it stands I end up way out of my depth real fast. <rbray> Tom and I will add this our list for tomorrow. Not sure how to resolve this just yet, but we basically need a bug manager. <tomf1> What are we looking for with this? <rbray> And of course both of us are swamped. <rbray> Someone to watch trac, assign defects, make sure the target fix version is set, etc. <rbray> Oh, and don't forget they first need to go back through and cleanup the tickets we have. <geojason> I have a feeling that we have a number of bugs that have either been fixed in 2.0, or are impossible to reproduce without more detail and should be closed. <geojason> Hard to deal with though. <rbray> Yea, it is a massive time sync. <rbray> I'll table that as another action for Tom and I to think about. <rbray> anything else? We are out of time. <tomf1> yes, I've asked for more details in some tickets, but there have not been updates, so I'll close those now <tomf1> ...a few months to provide more details should be enough I would think <rbray> Yea <rbray> OK, lets adjourn. Thanks everyone. <geojason> Bye! <bdechant> bye <HarisK> bye