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 http://dev-eap.ennoble.com.a
  u/survey.zip
<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> http://dev-eap.ennoble.com.au/survey.zip
<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!