Changes between Initial Version and Version 1 of PscMeeting03-31-2011r2


Ignore:
Timestamp:
Apr 1, 2011, 8:27:44 AM (13 years ago)
Author:
trevorwekel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PscMeeting03-31-2011r2

    v1 v1  
     1[wiki:ProjectSteeringCommittee Project Steering Committee - Home]
     2
     3== Meeting Info ==
     4
     5This meeting of the !MapGuide PSC takes place Thursday, March 31, 2011 at 20:00 UTC (4:00 PM Eastern / 2:00pm Mountain).
     6
     7Meeting Chair:
     8
     9PSC 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
     10
     11Location:  The meeting will be held on IRC at [irc://irc.freenode.net/mapguide #mapguide]
     12
     13== Agenda ==
     14
     15 * Appoint a Meeting Secretary
     16 * Ticket #1647 (Zac)
     17 * RFC 111 (Zac)
     18 * RFC 69 (Zac)
     19 * Resourcing and funding for automated builds (Trevor)
     20 * NUnit versus JUnit for Web Extensions testing (Trevor)
     21 * Target platforms for !MapGuide 2.3 (Trevor)
     22 * General discussion on Sponsorship (Trevor)
     23 * GeoREST (Zac)
     24 * Disqus to Wiki (Zac)
     25
     26== Minutes ==
     27
     28PSC Members present: Bob, Bruce, Tom, Haris, Jackie, Zac, Trevor
     29
     30=== Ticket #1647 ===
     31The King.Oracle Provider is a key component to the 2.2 Release.  Hold back the release until ticket is addressed.
     32=== RFC 111 ===
     33SVN-enabled directories for Fusion and Ajax should be included in the installer as an option.  A new installer
     34screen should be added to prompt the user as to whether or not the SVN directories should be installed.
     35=== RFC 69 ===
     36Not discussed.
     37=== Resourcing and funding for automated builds ===
     38Amazon EC2 should be investigated as an option for build infrastructure.  Build automation is not required at this time.[[BR]]
     39ACTION: Trevor to investigate Amazon EC2 as an option.
     40=== NUnit versus JUnit for Web Extensions testing ===
     41Verification of all three API languages would be preferred.  Build automation has been put on hold.
     42=== Target platforms for !MapGuide 2.3 ===
     43Current platform support (Ubuntu) should be improved before introducing new platforms.[[BR]]
     44ACTION: Zac and Trevor to perform test compilation on Ubuntu 10 (gcc 4.4) 32 bit and 64 bit (time permitting)
     45=== General discussion on Sponsorship ===
     46Not discussed.
     47=== GeoREST ===
     48Not discussed.
     49=== Disqus to Wiki ===
     50Information is easily lost in the mailing lists.  A commenting plugin for Trac (Disqus) would be useful.[[BR]]
     51ACTION: Zac to check with SAC on including Disqus 
     52
     53=== Full transcript ===
     54
     55{{{
     56
     57* Now talking in #MapGuide
     58* Topic is 'MapGuide Open Source | Home: http://mapguide.osgeo.org/ | Bugs:
     59http://trac.osgeo.org/mapguide | See Also: #OSGeo #FDO | Stats: http://www.ohloh.net/proj
     60ects/4656 -and- http://cia.navi.cx/stats/project/MapGuide'
     61* Set by unknown on Thu May 29 13:24:17
     62* zac has joined #MapGuide
     63* BruceD has joined #MapGuide
     64<zac> morning!
     65<BruceD> hello everyone
     66<trevorw> Good morning Zac, good afternoon Bruce
     67* rbray has joined #MapGuide
     68<trevorw> Zac, will Jackie be able to join?
     69<trevorw> Hi Bob
     70<zac> yep
     71<rbray> Hi Trevor, just so you know I am in a meeting that is running over I will be here
     72  100% when I can
     73* jng has joined #MapGuide
     74<trevorw> Haris and Paul indicated that they should be able to make it.  Let's wait
     75  another minute or two.
     76<jng> It's 2003 all over again. The last time I actually remembered how to use irc :P
     77<zac> feels like winter in melbourne at this time, brrrr, i'll be cognitive after this
     78  coffee kicks in
     79<trevorw> Does anyone have any agenda items to add?  Time permitting, I would like to add
     80  NUnit and/or JUnit for web extensions unit testing.
     81<zac> rfc 111
     82<zac> rfc 69
     83<zac> georest
     84<zac> adding disqus to the wiki
     85<jng> #1647 being a 2.2 blocker
     86* tomf_ has joined #MapGuide
     87<trevorw> Ok.  That's a big agenda.  I can do minutes.  Let me do a quick ordering of the
     88  agenda items.
     89<trevorw> Is everyone ok with this order: #1647, RFC 111, RFC 69, Resourcing/Funding
     90  Automated Builds, NUnit/JUnit, Target Platforms for 2.3, General Sponsorship
     91  Discussion, GeoREST, Disqus to Wiki
     92<BruceD> sure
     93<zac> http://trac.osgeo.org/mapguide/ticket/1647
     94<trevorw> The description sounds serious to me.
     95<zac> the fix is to select from dual instead of the source table, i think it's a simple
     96  fix
     97<BruceD> Definitely needs fixing
     98<jng> Not
     99<jng> mapguide's fault but shipping a provider with this serious defect is bad
     100<zac> fyi: we discovered it using whilst monitoring the logs using baretail for windows
     101<trevorw> So any spatial extents call will basically lock up the provider?
     102<jng> Yes
     103<jng> Well, let's qualify that
     104<jng> Spatial Extents call on any Oracle table of sufficient size (let's say > 1k rows)
     105<jng> because that's how many MBRs we get back (the same one too!)
     106<trevorw> Yep.  That's serious.  +1 to hold release.  Do we need another release
     107  candidate?
     108<zac> ennoble will test it, i think we can skip a RC
     109<trevorw> Sounds good.  I can roll the provider binaries into the final build.
     110<BruceD> eta on when this will be fixed?
     111<jng> haris could tell us, we emailed him a detailed solution for the problem
     112<BruceD> hopefully soon as this release has been delay long enough
     113<zac> while we are waiting, here's the results of the survey http://dev-eap.ennoble.com.a
     114  u/survey.zip
     115<trevorw> Haris is having trouble with IRC (new PC)
     116* HarisK has joined #MapGuide
     117<HarisK> hi, sorry for being late
     118<trevorw> Hi Haris, we are discussing http://trac.osgeo.org/mapguide/ticket/1647
     119<HarisK> I read email and quickly looked at code and unitests
     120<HarisK> don't have answer, but i believe i should be able to do it tommorow
     121<trevorw> Perfect!  Sounds like we should hold the 2.2 release for it.
     122<trevorw> +1 wait for 1647
     123<zac> +1
     124<jng> +1
     125<BruceD> +1
     126<HarisK> +1
     127<trevorw> Next agenda item RFC 111
     128<trevorw> Zac, can you give us an update?
     129<zac> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc111
     130<zac> so there's been discussions on users and internals
     131<zac> i ran the survery
     132<zac> http://dev-eap.ennoble.com.au/survey.zip
     133<zac> 29 responses, most users know subversion
     134<zac> 78% are in favour of this approach
     135<zac> plus the main developer for fusion
     136<zac> a few people want zip files or a exe installer which only does basic merging
     137<zac> i would suggest the other options require more work and are not as complete,
     138  nothing blocks the other solutions being implemented
     139<trevorw> if we go with this approach i would personally prefer to keep the .svn
     140  directories out of the installers and release an .svn zip file along with the
     141  installers.
     142<zac> in addtion, we require any patches as subversions diffs, why expect our users not
     143  to enjoy the same ease of use
     144<tomf_> What's the reason for keeping the .svn files out of the installers? Security?
     145<zac> it can be an install flag, on be default i'd suggest
     146<HarisK> .svn files would be some option to install ? users will have option of "plain"
     147  install without need to hear about svn ?
     148<trevorw> it doubles the size of the install set.  I suspect there would be no security
     149  issues.
     150<zac> even if the users don't use svn, it makes no impact on use..  we can add a rule to
     151  block .svn dirs via apache
     152<jng> Modding the wix installer would be a PITA (it prefers install features grouped by
     153  directories) .svn directories being all over the shop is a bit of a monkey wrench.
     154  Doesn't mean it's impossible tho
     155<tomf_> My preference is to install them (no option not to) if size is the only concern.
     156<zac> text files compress well :)
     157<jng> What's the scope of retaining .svn directories?
     158<trevorw> one quick question - does svn care about the root directory structure?  the
     159  installed web directory structure is not the same as oem/fusion + web/src
     160<jng> I'm just sampling the .svn size of the stuff we want to retain svn awareness
     161  (mapadmin/mapviewernet/mapviewerphp/mapviewerjsp/schemareport/stdicons/viewerfiles)
     162<zac> we can drop a .svn folder in the root web dir with only certain directories under
     163  svn
     164<jng> The combined size of these .svn dirs is negligible
     165<HarisK> i understand .svn files as developers stuff and I  think that we would need just
     166  standard user installation of MG
     167<trevorw> the proposal is to include the .svn directories in the installer (please
     168  correct me if i am wrong)
     169<jng> yes
     170<tomf_> Users who don't want to use .svn can ignore them.  Developers can use them.
     171<jng> non-svn users won't notice any difference
     172<zac> this RFC will really help the project, allowing us to release more often (tm)
     173<trevorw> other questions? are we ok to vote?
     174<HarisK> we have couple of larger enterprise customers and there is no way we could
     175  update there trough .svn and i don't think their admin would like it either
     176<HarisK> just my 2 cents
     177<jng> I assume MGE uses a separate installer packaging process
     178<zac> ok, but then you simply don't use it?
     179<tomf_> I doubt that MGE would install the .svn files
     180<zac> shall we vote?
     181<trevorw> hmm... some admins might not like the extra stuff hanging around.  An installer
     182  optioned turned off by default?
     183<HarisK> MGE ? I ment larger companies which uses MG OS
     184<zac> on by default
     185<HarisK> and admins in those companies don't like some extra stuff
     186<HarisK> yes trewor, that was my point
     187<jng> Is the attack surface being expanded by including .svn directories? Is this the
     188  concern?
     189<HarisK> sorry for name typo, Trevor
     190<trevorw> i think it's a FUD argument.  don't know what it is, don't like it.
     191<zac> @jng no because it's open source and we can hide them via webserver rules
     192<trevorw> how about .svn option off by default - this is current behaviour.
     193<zac> but most users like this feature, fussy admins can disable it
     194<jng> that's acceptable for me. It's just one check of the tickbox. We're not all *that*
     195  lazy!
     196<trevorw> 3rd party ISVs may have their own copy of the web directories under their own
     197  svn (or other version control) tree as well.
     198<tomf_> I haven't been convinced to move from my original position of installign them. 
     199  We could provide a script for those few who want to remove them
     200<HarisK> we do a lot of development but still,  I really can't see us updating MG trough
     201  svn on working customer site
     202<HarisK> I can see doing that on test/development sites
     203<zac> those 3rd parties are already doing post install mods
     204<BruceD> @Haris agree
     205<trevorw> sounds like svn dirs are useful for dev/test machines only.  option off by
     206  default?
     207<zac> most installs are dev test anyway right? target the base
     208<zac> every production server i maintain, code is deployed only thru subversion
     209<rbray> personally I'd never use this on a production server, dev/test servers yea it's a
     210  great idea
     211<zac> so lets make it a individual installer screen?
     212<rbray> but I am fine with the concept of an option in the installer - don't really care
     213  which way it defaults
     214<trevorw> installer option off by default to maintain existing behaviour?
     215<trevorw> and I like the separate screen idea.
     216<HarisK> +1
     217<BruceD> +1
     218<rbray> +1
     219<trevorw> +1
     220<jng> +1
     221<zac> +1
     222<tomf_> +0
     223<trevorw> Do we have time for another agenda item?
     224<zac> we can gauge the  feedback during RC's on the default option
     225<HarisK> i have time
     226<zac> yep
     227<BruceD> I can stay
     228<jng> sure
     229<zac> let's talk builds next?
     230<trevorw> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc69 was next up
     231<trevorw> We can goto build next if you like zac
     232<zac> i think if we have time constraints, builds are more important
     233<trevorw> Ok.  Resourcing / Funding for Automated builds
     234<zac> my thoughts on the linux builds is, lets fix the builds rather than support so many
     235  platform builds?
     236<zac> 90% plus of cloud servers run ubuntu right?
     237<trevorw> Yes.  We currently support CentOS/RHEL 5 and Ubuntu 9.  Ubuntu 10 is
     238  problematic with 2.2 due to 3rd party dependencies.  2.3 may be better.
     239<zac> is the GSC work salavageable?
     240<trevorw> I believe Bruce may have looked at it as part of the 3rd party upgrades in 2.3.
     241<trevorw> (berkeley db/xml mostly)
     242<zac> vs2010 support comes in there as well right?
     243<BruceD> that is lots more work
     244<BruceD> 2010 compiler support that is
     245<BruceD> 2010 ide is not an issue
     246<trevorw> bruce - do you know if oem compiles with gcc 4.4? (Ubuntu 10, RHEL 6)
     247<zac> perhaps a 3.0 goal, we should just push 2.3 out soon...
     248<BruceD> dont know have not tried those distros
     249<zac> i'm on 10.10 64-bit here currently, haven't tried a build tho
     250<trevorw> ok.  native gcc 4.4 would be good for Ubuntu.  64 bit linux would be good too. 
     251  For timelines, I was thinking september for MG 2.3 to put us in the running for FOSS4G
     252  2011
     253<trevorw> i guess we will have to perform test compiles on those platforms to see how
     254  close we are.
     255<zac> are all 2.3 RFC's completed?
     256<zac> quickplot has already bled into 2.3
     257<zac> i mean snuck into 2.2
     258<trevorw> Build question - do we want automated builds?
     259<trevorw> zac, can you and I take test builds for Linux platform support as a task item
     260  for next meeting?
     261<zac> sure
     262<trevorw> Ok. Great.  that should put us in better shape to answer the platforms question.
     263<trevorw> For automated builds - do we want to expend the effort to do them?
     264<zac> only needed for server/api mods, i'd suggest occasional builds, less problems...
     265  i.e. an RFC is completed
     266<trevorw> Yes.  They do not have to be daily.  Should they be automated?
     267<trevorw> (ie. not built by hand)
     268<zac> i'd say it's your call trevor, as your doing the work..
     269<trevorw> True.  OTX Systems has about $10k invested in hardware and software licenses
     270  and another $4k/year in ISP fees.
     271<trevorw> without additional resources/funding, it will be difficult for me to provide
     272  build automation.
     273<trevorw> I've been looking into corporate sponsorship for MGOS.  But I do not believe we
     274  (the PSC) have decided where to allocate any funding we get.
     275<tomf_> Has there been any investigation in looking at cloud solutions for compiling?  It
     276  seems that would reduce the hardware costs at least.
     277<trevorw> Did a quick compare with Connectria.  $9k/year for the VMs we are running.
     278<trevorw> (6 VMs, 225GB disk, 7GB ram)
     279<trevorw> Hardware + software is half, ISP is the other half.
     280<zac> how come a normal ADSL wouldn't suffice?
     281<zac> http://trac.osgeo.org/mapguide/wiki/MapGuideRfc111 (updated with votes and the
     282  optional installer info)
     283<trevorw> a typical ADSL line is only 1 Mbit/sec (100 kbytes/sec).  That would only
     284  handle one VPN user for the builds.  Builds downloads would be very slow.
     285<trevorw> (20+ minutes for an installer exe)
     286<trevorw> If we are not doing regular builds, and there is no build collaboration, a 1
     287  Mbit line might be workable.
     288<zac> s3 is always an option for downloads, 10c a gig for t/f  - 14c for storage
     289<tomf_> With something like Amazon Web Service, there is the option of running the VMs
     290  only when they are required; no paying when they aren't required. If we are only doing
     291  builds once in a while that could save on costs.
     292<zac> ennoble will host on s3
     293<zac> the hardware exists already?
     294<tomf_> S3 is good, also posting onto the download site on OSGeo.org would work wouldn't
     295  it?
     296<trevorw> Yes.  The hardware is in my basement.  The VMs are already set up.  I already
     297  have a ~5Mbit line.
     298<trevorw> A build mirror would work.  Nightly (even weekly) builds would be too much
     299  volume for OSGeo.
     300<zac> using amazon cloudfront is an option, dead simple CDN mirror
     301<trevorw> The hardware should be ok for another year.
     302<jng> wrt frequency I like zac's suggestion of occasional builds
     303<jng> It'd be like preview releases for Maestro
     304<zac> on sponsorship, how about adding an info/support the project page to the installer?
     305<jng> installer ui or start menu/desktop links?
     306<zac> definately not on the desktop, otherwise yes
     307<trevorw> should I write up an RFC on using sponsorship funding for builds infrastructure?
     308<jng> I think there's a perception problem
     309<jng> I think most users think free as in beer instead of free as in speech
     310<jng> We need to drive home the point that Open Source != a free lunch
     311<trevorw> I can detail the hardware/software/isp costs for doing the builds in the rfc
     312<trevorw> do we want to estimate person time to maintain the builds?
     313<rbray> trevor, I also think Tom's idea of using Amazon on demand instances is a good one
     314  to explore
     315<trevorw> bob, does Amazon support Windows images?
     316<rbray> yes
     317<zac> yep, twice the price of linux instances
     318<rbray> still for a 2 hour build it's cheap
     319<rbray> and no hardware to maintain
     320<rbray> ISP costs
     321<rbray> etc
     322<zac> using an ebs image you just fire it up as required, only pay for the storage of the
     323  ebs volume
     324<trevorw> If we are only doing sporadic builds, it would work.  The personnel cost to set
     325  it up could be signficant depending on the level of automation.
     326<trevorw> Does Amazon offer backup?
     327<rbray> even if you build twice a week or even daily - I think it would save big $$$
     328<zac> yep, snapshots are available
     329<trevorw> No.  Not snapshots.  Backup on separate disk.
     330<HarisK> I am using amazon for MapGuide on Windows and have very positive experience
     331<zac> you can copy the images to another EBS volume or on s3
     332<trevorw> I think it can take anywhere from 1 to 3 days to set up a single build VM
     333  (install software, etc).
     334<trevorw> I will look into Amazon.
     335<zac> i'm not sure if it helps, but as a MS partner, i have a free copy of 2008 server we
     336  could use, not sure if BYO makes EC2 cheaper or if my license allows it
     337<trevorw> OTX Systems has already purchased a Win 2008 Server and Win 2008 Web license
     338  for the build infrastructure.
     339<zac> ok, shall we move on to junit v nunit?
     340<trevorw> Ok.  If we were going to do build automation with Cruise Control (java or
     341  .net), there is native support for running unit tests with junit or nunit.
     342<trevorw> Which would be preferable if we were going to rewrite the web extensions unit
     343  tests?
     344<BruceD> Either one would work for me
     345<jng> .net/nunit for me
     346<trevorw> Do we also need to run the unit tests on both Windows and Linux?
     347<zac> preferrably
     348<BruceD> Doing this helps validate on both platforms
     349<jng> I assume we're testing the robustness of the web extensions regardless of wrapper
     350  language and not the wrapper itself?
     351<zac> (aside: go Jackie on the recent response on the mailing list)
     352<trevorw> both - the wrapper is a fair bit of generated code and their are platform
     353  differences.  Perhaps we need both nunit and junit for better coverage?
     354<zac> would it help to have a php/.net/.jsp page which runs the tests in their own
     355  language?
     356<trevorw> Then we need to install and configure a webserver too.  nunit/junit could run
     357  out of the box without it.
     358<trevorw> maybe use nunit on Windows as the primary "unit test platform" and port the
     359  tests to junit/linux time permitting?
     360<jng> Is a webserver necessary?
     361<trevorw> webserver is not required for junit/nunit
     362<jng> MG API is usable outside the webserver provided webconfig.ini/MgInitializeWebTier
     363  setup is performed before doing anything
     364<trevorw> ok.  sounds like we would prefer coverage for all three api languages.
     365<trevorw> should we bump the rest of the agenda items to the next meeting?
     366<zac> just very quickly, any thoughts on the disqus for the wiki/doco ?
     367<zac> similiar to what adobe does
     368<zac> http://help.adobe.com/en_US/ColdFusion/9.0/CFMLRef/WSc3ff6d0ea77859461172e0811cbec1
     369  bb49-7fc4.html
     370<trevorw> are we replacing trac?
     371<zac> it's just a js plugin which allows commenting
     372<zac> like 10 lines of template code
     373<zac> stuff get's lost on the mailing list rather quickly
     374<trevorw> we would probably have to get OSGeo SAC to approve it if we wanted to use it.
     375<trevorw> agree with the mailing list comment...
     376<zac> i think it would be good to capture doco requests
     377<HarisK> just a late remark on build/test topic, sorry i was out of office
     378<BruceD> I'm fine with it and agree with the mailing list issue
     379<HarisK> that we don't put much more effort into build-test-integration toools
     380<BruceD> Anyways sorry I have to run
     381<HarisK> while it seems development rate is quite low recently
     382<BruceD> Nice chatting with you all again :)
     383<HarisK> thanks
     384<trevorw> thanks bruce
     385<BruceD> Bye
     386* BruceD Quit (Quit: ChatZilla 0.9.86 [Firefox
     3873.5.14/20101001172330])
     388<zac> an example http://www.exploreaustralia.net.au/Victoria/Grampians-and-Central-West/G
     389  rampians-National-Park see the comments tab
     390<zac> @Harris I agree
     391* jng Quit (Ping timeout: 240 seconds)
     392* jng has joined #MapGuide
     393<zac> do we really need to ping the SAC to include javascript on our wiki pages?
     394<trevorw> i do not know.  does trac allow javascript to be embedded?
     395<jng> @zac, It does sound like an OSGeo infrastructure problem
     396<zac> dunno, we use jira for work... it's just templates right... Jackie you've played
     397  with trac before?
     398* rbray Quit
     399<zac> ok, i'll follow that up with the SAC
     400<trevorw> Ok.  shall we adjourn?
     401<HarisK> I need to go as well
     402<HarisK> thank you all
     403<trevorw> thanks haris
     404<HarisK> and thanks for organising it
     405<jng> thanks from me too
     406<zac> cheers Trevor et al!
     407<trevorw> cheers!
     408
     409}}}