[wiki:ProjectSteeringCommittee Project Steering Committee - Home] == Meeting Info == This meeting of the !MapGuide PSC takes place Thursday, March 31, 2011 at 20:00 UTC (4:00 PM Eastern / 2:00pm Mountain). Meeting Chair: PSC Local Times: http://www.timeanddate.com/worldclock/meetingdetails.html?year=2011&month=3&day=31&hour=20&min=0&sec=0&p1=55&p2=152&p3=736&p4=188 Location: The meeting will be held on IRC at [irc://irc.freenode.net/mapguide #mapguide] == Agenda == * Appoint a Meeting Secretary * Ticket #1647 (Zac) * RFC 111 (Zac) * RFC 69 (Zac) * Resourcing and funding for automated builds (Trevor) * NUnit versus JUnit for Web Extensions testing (Trevor) * Target platforms for !MapGuide 2.3 (Trevor) * General discussion on Sponsorship (Trevor) * GeoREST (Zac) * Disqus to Wiki (Zac) == Minutes == PSC Members present: Bob, Bruce, Tom, Haris, Jackie, Zac, Trevor === Ticket #1647 === The King.Oracle Provider is a key component to the 2.2 Release. Hold back the release until ticket is addressed. === RFC 111 === SVN-enabled directories for Fusion and Ajax should be included in the installer as an option. A new installer screen should be added to prompt the user as to whether or not the SVN directories should be installed. === RFC 69 === Not discussed. === Resourcing and funding for automated builds === Amazon EC2 should be investigated as an option for build infrastructure. Build automation is not required at this time.[[BR]] ACTION: Trevor to investigate Amazon EC2 as an option. === NUnit versus JUnit for Web Extensions testing === Verification of all three API languages would be preferred. Build automation has been put on hold. === Target platforms for !MapGuide 2.3 === Current platform support (Ubuntu) should be improved before introducing new platforms.[[BR]] ACTION: Zac and Trevor to perform test compilation on Ubuntu 10 (gcc 4.4) 32 bit and 64 bit (time permitting) === General discussion on Sponsorship === Not discussed. === GeoREST === Not discussed. === Disqus to Wiki === Information is easily lost in the mailing lists. A commenting plugin for Trac (Disqus) would be useful.[[BR]] ACTION: Zac to check with SAC on including Disqus === Full transcript === {{{ * Now talking in #MapGuide * Topic is 'MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs: http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/proj ects/4656 -and- http://cia.navi.cx/stats/project/MapGuide' * Set by unknown on Thu May 29 13:24:17 * zac has joined #MapGuide * BruceD has joined #MapGuide morning! hello everyone Good morning Zac, good afternoon Bruce * rbray has joined #MapGuide Zac, will Jackie be able to join? Hi Bob yep Hi Trevor, just so you know I am in a meeting that is running over I will be here 100% when I can * jng has joined #MapGuide Haris and Paul indicated that they should be able to make it. Let's wait another minute or two. It's 2003 all over again. The last time I actually remembered how to use irc :P feels like winter in melbourne at this time, brrrr, i'll be cognitive after this coffee kicks in Does anyone have any agenda items to add? Time permitting, I would like to add NUnit and/or JUnit for web extensions unit testing. rfc 111 rfc 69 georest adding disqus to the wiki #1647 being a 2.2 blocker * tomf_ has joined #MapGuide Ok. That's a big agenda. I can do minutes. Let me do a quick ordering of the agenda items. Is everyone ok with this order: #1647, RFC 111, RFC 69, Resourcing/Funding Automated Builds, NUnit/JUnit, Target Platforms for 2.3, General Sponsorship Discussion, GeoREST, Disqus to Wiki sure http://trac.osgeo.org/mapguide/ticket/1647 The description sounds serious to me. the fix is to select from dual instead of the source table, i think it's a simple fix Definitely needs fixing Not mapguide's fault but shipping a provider with this serious defect is bad fyi: we discovered it using whilst monitoring the logs using baretail for windows So any spatial extents call will basically lock up the provider? Yes Well, let's qualify that Spatial Extents call on any Oracle table of sufficient size (let's say > 1k rows) because that's how many MBRs we get back (the same one too!) Yep. That's serious. +1 to hold release. Do we need another release candidate? ennoble will test it, i think we can skip a RC Sounds good. I can roll the provider binaries into the final build. eta on when this will be fixed? haris could tell us, we emailed him a detailed solution for the problem hopefully soon as this release has been delay long enough while we are waiting, here's the results of the survey (link removed) Haris is having trouble with IRC (new PC) * HarisK has joined #MapGuide hi, sorry for being late Hi Haris, we are discussing http://trac.osgeo.org/mapguide/ticket/1647 I read email and quickly looked at code and unitests don't have answer, but i believe i should be able to do it tommorow Perfect! Sounds like we should hold the 2.2 release for it. +1 wait for 1647 +1 +1 +1 +1 Next agenda item RFC 111 Zac, can you give us an update? http://trac.osgeo.org/mapguide/wiki/MapGuideRfc111 so there's been discussions on users and internals i ran the survery (link removed) 29 responses, most users know subversion 78% are in favour of this approach plus the main developer for fusion a few people want zip files or a exe installer which only does basic merging i would suggest the other options require more work and are not as complete, nothing blocks the other solutions being implemented if we go with this approach i would personally prefer to keep the .svn directories out of the installers and release an .svn zip file along with the installers. in addtion, we require any patches as subversions diffs, why expect our users not to enjoy the same ease of use What's the reason for keeping the .svn files out of the installers? Security? it can be an install flag, on be default i'd suggest .svn files would be some option to install ? users will have option of "plain" install without need to hear about svn ? it doubles the size of the install set. I suspect there would be no security issues. even if the users don't use svn, it makes no impact on use.. we can add a rule to block .svn dirs via apache Modding the wix installer would be a PITA (it prefers install features grouped by directories) .svn directories being all over the shop is a bit of a monkey wrench. Doesn't mean it's impossible tho My preference is to install them (no option not to) if size is the only concern. text files compress well :) What's the scope of retaining .svn directories? one quick question - does svn care about the root directory structure? the installed web directory structure is not the same as oem/fusion + web/src I'm just sampling the .svn size of the stuff we want to retain svn awareness (mapadmin/mapviewernet/mapviewerphp/mapviewerjsp/schemareport/stdicons/viewerfiles) we can drop a .svn folder in the root web dir with only certain directories under svn The combined size of these .svn dirs is negligible i understand .svn files as developers stuff and I think that we would need just standard user installation of MG the proposal is to include the .svn directories in the installer (please correct me if i am wrong) yes Users who don't want to use .svn can ignore them. Developers can use them. non-svn users won't notice any difference this RFC will really help the project, allowing us to release more often (tm) other questions? are we ok to vote? we have couple of larger enterprise customers and there is no way we could update there trough .svn and i don't think their admin would like it either just my 2 cents I assume MGE uses a separate installer packaging process ok, but then you simply don't use it? I doubt that MGE would install the .svn files shall we vote? hmm... some admins might not like the extra stuff hanging around. An installer optioned turned off by default? MGE ? I ment larger companies which uses MG OS on by default and admins in those companies don't like some extra stuff yes trewor, that was my point Is the attack surface being expanded by including .svn directories? Is this the concern? sorry for name typo, Trevor i think it's a FUD argument. don't know what it is, don't like it. @jng no because it's open source and we can hide them via webserver rules how about .svn option off by default - this is current behaviour. but most users like this feature, fussy admins can disable it that's acceptable for me. It's just one check of the tickbox. We're not all *that* lazy! 3rd party ISVs may have their own copy of the web directories under their own svn (or other version control) tree as well. I haven't been convinced to move from my original position of installign them. We could provide a script for those few who want to remove them we do a lot of development but still, I really can't see us updating MG trough svn on working customer site I can see doing that on test/development sites those 3rd parties are already doing post install mods @Haris agree sounds like svn dirs are useful for dev/test machines only. option off by default? most installs are dev test anyway right? target the base every production server i maintain, code is deployed only thru subversion personally I'd never use this on a production server, dev/test servers yea it's a great idea so lets make it a individual installer screen? but I am fine with the concept of an option in the installer - don't really care which way it defaults installer option off by default to maintain existing behaviour? and I like the separate screen idea. +1 +1 +1 +1 +1 +1 +0 Do we have time for another agenda item? we can gauge the feedback during RC's on the default option i have time yep I can stay sure let's talk builds next? http://trac.osgeo.org/mapguide/wiki/MapGuideRfc69 was next up We can goto build next if you like zac i think if we have time constraints, builds are more important Ok. Resourcing / Funding for Automated builds my thoughts on the linux builds is, lets fix the builds rather than support so many platform builds? 90% plus of cloud servers run ubuntu right? Yes. We currently support CentOS/RHEL 5 and Ubuntu 9. Ubuntu 10 is problematic with 2.2 due to 3rd party dependencies. 2.3 may be better. is the GSC work salavageable? I believe Bruce may have looked at it as part of the 3rd party upgrades in 2.3. (berkeley db/xml mostly) vs2010 support comes in there as well right? that is lots more work 2010 compiler support that is 2010 ide is not an issue bruce - do you know if oem compiles with gcc 4.4? (Ubuntu 10, RHEL 6) perhaps a 3.0 goal, we should just push 2.3 out soon... dont know have not tried those distros i'm on 10.10 64-bit here currently, haven't tried a build tho ok. native gcc 4.4 would be good for Ubuntu. 64 bit linux would be good too. For timelines, I was thinking september for MG 2.3 to put us in the running for FOSS4G 2011 i guess we will have to perform test compiles on those platforms to see how close we are. are all 2.3 RFC's completed? quickplot has already bled into 2.3 i mean snuck into 2.2 Build question - do we want automated builds? zac, can you and I take test builds for Linux platform support as a task item for next meeting? sure Ok. Great. that should put us in better shape to answer the platforms question. For automated builds - do we want to expend the effort to do them? only needed for server/api mods, i'd suggest occasional builds, less problems... i.e. an RFC is completed Yes. They do not have to be daily. Should they be automated? (ie. not built by hand) i'd say it's your call trevor, as your doing the work.. True. OTX Systems has about $10k invested in hardware and software licenses and another $4k/year in ISP fees. without additional resources/funding, it will be difficult for me to provide build automation. I've been looking into corporate sponsorship for MGOS. But I do not believe we (the PSC) have decided where to allocate any funding we get. Has there been any investigation in looking at cloud solutions for compiling? It seems that would reduce the hardware costs at least. Did a quick compare with Connectria. $9k/year for the VMs we are running. (6 VMs, 225GB disk, 7GB ram) Hardware + software is half, ISP is the other half. how come a normal ADSL wouldn't suffice? http://trac.osgeo.org/mapguide/wiki/MapGuideRfc111 (updated with votes and the optional installer info) a typical ADSL line is only 1 Mbit/sec (100 kbytes/sec). That would only handle one VPN user for the builds. Builds downloads would be very slow. (20+ minutes for an installer exe) If we are not doing regular builds, and there is no build collaboration, a 1 Mbit line might be workable. s3 is always an option for downloads, 10c a gig for t/f - 14c for storage With something like Amazon Web Service, there is the option of running the VMs only when they are required; no paying when they aren't required. If we are only doing builds once in a while that could save on costs. ennoble will host on s3 the hardware exists already? S3 is good, also posting onto the download site on OSGeo.org would work wouldn't it? Yes. The hardware is in my basement. The VMs are already set up. I already have a ~5Mbit line. A build mirror would work. Nightly (even weekly) builds would be too much volume for OSGeo. using amazon cloudfront is an option, dead simple CDN mirror The hardware should be ok for another year. wrt frequency I like zac's suggestion of occasional builds It'd be like preview releases for Maestro on sponsorship, how about adding an info/support the project page to the installer? installer ui or start menu/desktop links? definately not on the desktop, otherwise yes should I write up an RFC on using sponsorship funding for builds infrastructure? I think there's a perception problem I think most users think free as in beer instead of free as in speech We need to drive home the point that Open Source != a free lunch I can detail the hardware/software/isp costs for doing the builds in the rfc do we want to estimate person time to maintain the builds? trevor, I also think Tom's idea of using Amazon on demand instances is a good one to explore bob, does Amazon support Windows images? yes yep, twice the price of linux instances still for a 2 hour build it's cheap and no hardware to maintain ISP costs etc using an ebs image you just fire it up as required, only pay for the storage of the ebs volume If we are only doing sporadic builds, it would work. The personnel cost to set it up could be signficant depending on the level of automation. Does Amazon offer backup? even if you build twice a week or even daily - I think it would save big $$$ yep, snapshots are available No. Not snapshots. Backup on separate disk. I am using amazon for MapGuide on Windows and have very positive experience you can copy the images to another EBS volume or on s3 I think it can take anywhere from 1 to 3 days to set up a single build VM (install software, etc). I will look into Amazon. i'm not sure if it helps, but as a MS partner, i have a free copy of 2008 server we could use, not sure if BYO makes EC2 cheaper or if my license allows it OTX Systems has already purchased a Win 2008 Server and Win 2008 Web license for the build infrastructure. ok, shall we move on to junit v nunit? Ok. If we were going to do build automation with Cruise Control (java or .net), there is native support for running unit tests with junit or nunit. Which would be preferable if we were going to rewrite the web extensions unit tests? Either one would work for me .net/nunit for me Do we also need to run the unit tests on both Windows and Linux? preferrably Doing this helps validate on both platforms I assume we're testing the robustness of the web extensions regardless of wrapper language and not the wrapper itself? (aside: go Jackie on the recent response on the mailing list) both - the wrapper is a fair bit of generated code and their are platform differences. Perhaps we need both nunit and junit for better coverage? would it help to have a php/.net/.jsp page which runs the tests in their own language? Then we need to install and configure a webserver too. nunit/junit could run out of the box without it. maybe use nunit on Windows as the primary "unit test platform" and port the tests to junit/linux time permitting? Is a webserver necessary? webserver is not required for junit/nunit MG API is usable outside the webserver provided webconfig.ini/MgInitializeWebTier setup is performed before doing anything ok. sounds like we would prefer coverage for all three api languages. should we bump the rest of the agenda items to the next meeting? just very quickly, any thoughts on the disqus for the wiki/doco ? similiar to what adobe does http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec1 bb49-7fc4.html are we replacing trac? it's just a js plugin which allows commenting like 10 lines of template code stuff get's lost on the mailing list rather quickly we would probably have to get OSGeo SAC to approve it if we wanted to use it. agree with the mailing list comment... i think it would be good to capture doco requests just a late remark on build/test topic, sorry i was out of office I'm fine with it and agree with the mailing list issue that we don't put much more effort into build-test-integration toools Anyways sorry I have to run while it seems development rate is quite low recently Nice chatting with you all again :) thanks thanks bruce Bye * BruceD Quit (Quit: ChatZilla 0.9.86 [Firefox 3.5.14/20101001172330]) an example http://www.exploreaustralia.net.au/Victoria/Grampians-and-Central-West/G rampians-National-Park see the comments tab @Harris I agree * jng Quit (Ping timeout: 240 seconds) * jng has joined #MapGuide do we really need to ping the SAC to include javascript on our wiki pages? i do not know. does trac allow javascript to be embedded? @zac, It does sound like an OSGeo infrastructure problem dunno, we use jira for work... it's just templates right... Jackie you've played with trac before? * rbray Quit ok, i'll follow that up with the SAC Ok. shall we adjourn? I need to go as well thank you all thanks haris and thanks for organising it thanks from me too cheers Trevor et al! cheers! }}}