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