Project Steering Committee - Home

Meeting Info

This meeting of the MapGuide PSC will take place Thursday, September 10, 2009 at 18:00 UTC (2:00 PM ET / noon MT / 11:00 AM PT).

Meeting Chair: Bob Bray

Universal Time: ​http://www.timeanddate.com/worldclock/fixedtime.html?month=9&day=10&year=2009&hour=12&min=0&sec=0&p1=55

Location: The meeting will be held on IRC at ​#mapguide

Agenda

• Appoint a Meeting Secretary
• The 2.1 Release
• Sponsorship ​#RFC83
• CCLA Forms
• Progress on the nightly builds
• RFC 69 does not has Funding/Resources has "Help Wanted"; can we approve before this section is filled in with a resource?

Minutes

PSC Members present: Jason, Bruce, Tom, Andy, Kenneth, Trevor.

The 2.1 Release

• The PSC should follow the posted release process http://mapguide.osgeo.org/releaseprocess.html
• Additional Fusion work may still be required for the release.
• Jason will release a MapGuide 2.1 beta based on Fusion trunk ASAP. The official release date is set for one month after the beta release.
• Jason and Trevor will clean the existing Trac tickets. 1.2 tickets will be blanket closed with a note to reopen if necessary. Retesting against 2.1 will be requested for all tickets submitted against 2.0.

Sponsorship

• Trevor will send RFC83 out to -internals and -users for review and contact Frank Warmerdam for details on the OSGeo sponsorship program.

CCLA Forms

• Tom will collaborate with Bob to create a Corporate Contributor License Agreement based on the existing Fdo agreement.

Progress on the nightly builds

• Trevor will migrate the existing build VMs to VMware based virtualization. Once the move is complete, work will continue on integrating the installers into the nightly build process. A link to the nightly builds will be posted on the MapGuide website once this has been completed.

RFC 69 Funding/Resources

• Since RFC 69 depends on Fdo RFC 40, work on this RFC will be delaying until the underlying Fdo functionality can be implemented.

End of meeting

Full transcript

Start of #mapguide buffer: Thu Sep 10 13:45:49 2009
* 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/proje
cts/4656 -and- http://cia.navi.cx/stats/project/MapGuide'
* Set by jasonbirch on Mon May 28 12:47:53
* bdechant (n=chatzill@ussclout1.autodesk.com) has joined #mapguide
* jasonbirch (n=jasonbir@osgeo/member/jasonbirch) has joined #mapguide
* amorsell (n=chatzill@76.178.132.188) has joined #mapguide
* tomf2 (n=tomf2@ussclout1.autodesk.com) has joined #mapguide
<jasonbirch> Are we meeting now?  Or did something else happen that i'm oblivious to? :)
* jasonbirch is still in vacation catchup mode
* amorsell (n=chatzill@76.178.132.188) Quit (Remote closed the connection)
<trevorw> Hi Jason, I think we are meeting.  Haris also accepted the meeting invite so 
  hopefully he will be able to join.
* tomf2 (n=tomf2@ussclout1.autodesk.com) Quit (Read error: 54 (Connection reset by peer))
* amorsell (n=chatzill@76.178.132.188) has joined #mapguide
<trevorw> I don't know about Bob and Paul though.
<bdechant> Tom is coming back - had to reboot his laptop
<trevorw> I think Bob wanted Tom to chair the meeting from last week since he couldn't 
  make it.
<bdechant> That might still be the plan
<trevorw> Hey Bruce, what happened to Tom?  Looks like his connection got turfed.
<bdechant> Look up a few comments :)
<jasonbirch> While we're here, if you're in Canada and wanting to travel before Dec 17, 
  book today with WestJet :)   http://www.redflagdeals.com/deals/main.php/alldeals/comment
  s/westjetcom_up_to_65_off_fall_travel_ends_september_10/
<trevorw> Hmm... maybe I should increase my font size :)
<bdechant> :)
* kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) Quit (Read error: 110 (Connection 
timed out))
<trevorw> I just checked the PSC page.  Looks like we need 2/3rds for quorum (6 people) if 
  we want to vote on anything.
<bdechant> Correct
<bdechant> I can chair this meeting if no one objects
* tomf2 (n=tomf2@132.188.64.150) has joined #mapguide
<tomf2> rebooted!
<bdechant> Should we get started?
<trevorw> Yes.  Let's get started.
* kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide
<bdechant> Ok - 1st agenda item is to appoint a meeting secretary
<bdechant> Any volunteers?
<trevorw> I can if no one has prior experience.  Not sure if I can cut and paste from my 
  chat client...
<bdechant> Most of us have had a turn
<bdechant> But thanks for volunteering Trevor :)
<bdechant> If you cannot cut/paste let me know and I can email the notes to you
<trevorw> Ok.  I'm good.  Looks like I can save the session to a file.
<bdechant> Next item on the list - the 2.1 Release
<bdechant> So what are we doing and when?
<kenneth_> I propose that we describe a formal release process to prevent lags like this 
  in the future
<kenneth_> From what I can see, the OpenLayers team seems to have a very nice process
<bdechant> agreed - Kenneth would you like to write that up and post it on our wiki?
<kenneth_> Basically, a release manager is appointed at the time a branch is made
<tomf2> Is it different than http://mapguide.osgeo.org/releaseprocess.html
<kenneth_> No, it looks similar
<tomf2> OK, we've had that from the start,  looks like we're just not following it
<bdechant> The problem is that we haven't been following it
<bdechant> Do we have an official Release Manager?
<trevorw> The posted release process we have seems reasonable.  I think part of the 
  problem is limited resources to back the release process - release manager and 
  developers to fix critical defects.
<trevorw> I believe Jason has been unoffically standing in as release manager this time 
  around.
<tomf2> Yes, resources are a problem, Autodesk used to do all this before, but those 
  resources are no longer available to us
<kenneth_> A thing that seems to be missing is the "pullup" state for tickets, which 
  developers can set when a ticket has a reasonable solution, and the release manager 
  should pull it into the release branch
<kenneth_> That makes the RM's job much easier
<trevorw> So ticket fixes are submitted as patches or to a sandbox?  Then someone has the 
  merge the fix into the release (candidate) branch?
<kenneth_> yes, or to trunk, but only the RM commits to the release branch
<tomf2> Is that is what is holding up the 2.1 release right now though?
<bdechant> That seems like a lot of work for the RM
<kenneth_> ok, I thinks its less work, just look at the list of open issues for the 
  release, follow up on anything that is missing a pullup tag, and merge the 
  patches/revisions for those marked for pullup
<trevorw> Yes.  It's a ton of work for the RM.  I think developers should be doing 
  approved submissions to 2.1.  They know what the fix is.  The RM should be giving 
  approval and figuring out what has to go in.
<kenneth_> its not a showstopper for me, just a suggestion, that seems to work really well 
  for OL
<trevorw> So how do we tag these pullup tickets?  I'm not sure the milestone and version 
  fields in trac are sufficent.
<trevorw> Do we need some sort of nomination/approval field?
<kenneth_> in the status field, where you have assigned, fixed, reopend, etc.
<kenneth_> afaik, there is no nomination/approval in OL trac
<kenneth_> the RM decides what fixes are good enough to make it into the release, and what 
  issues are holding it back
<kenneth_> pullup simply states that the ticket is fixed and reviewed, and that the 
  developers consider it ready for inclusion
<tomf2> Sorry, but can we move on.  I have some questions: What are we waiting for for the 
  next beta? About when are we targeting for 2.1?
<jasonbirch> Right now, just waiting for a Fusion that works.
<jasonbirch> Where works = something that doesn't entirely piss off everyone.
<kenneth_> perhaps the first item on the agenda should be two: How does 2.1 get released 
  ASAP, and how do we prevent future delays
<jasonbirch> From my perspective, the main problem has been a lack of resources to get 
  showstopper bugs fixed.
<jasonbirch> I can rev betas as often as required, but no point if things aren't getting 
  fixed.
<tomf2> How can we get things fixed?  Any ideas?
<kenneth_> considering that Fusion has it's own release cycle, shoud we consider not 
  including fusion (or just 1.1) in the 2.1 release?
<trevorw> Is there a list of showstopper issues published somewhere that we can track 
  against?  That might be what we are missing.
<jasonbirch> Perhaps we need tighter management of the Trac issues list.
<jasonbirch> Right now priorities are set by the submitter, and not really managed.
<jasonbirch> Well, not rigorously, anyway.
<trevorw> Exactly.  Trac doesn't tell us what we have to fix.  Maintaining the must fix 
  list should be the RM's and PSC's job.
<jasonbirch> Personally, I think part of the problem is that Trac is basically a 
  duplication of effort for ADSK
<jasonbirch> So we are left with confusion, no resources to manage, etc.
<kenneth_> would that make more people angry than further delaying the 2.1 release?
* kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) Quit (Remote closed the connection)
<jasonbirch> Trac _could_tell us that.
<jasonbirch> But it's hard for a non-technical manager to go back and reclassify existing 
  tickets, clean them up, etc.
<tomf2> I'm confused, what does Autodesk have to do with resources for fixing Fusion 
  defects?
* kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide
<jasonbirch> Nothing Tom, I'm talking about release process ni general.
<tomf2> Oh, OK
<jasonbirch> I'd be against releasing MapGuide without Fusion.
<jasonbirch> I'd be OK releasing it with current Fusion trunk though.
<tomf2> ...but the current Fusion trunk has too many problems?
<trevorw> Should we just create a page with the targeted 2.1 defects on the Trac website, 
  or can we mark the tickets somehow and run a query?
<jasonbirch> Especially if Fusion can't devote time to pushing a 2.x release.
<jasonbirch> We can mark the tickets, and I can build a custom query if required.
<jasonbirch> And then automatically bring these into a Wiki page.
<jasonbirch> But really, it's just a matter of setting the milestone.  I think.
<trevorw> That would be good.  And if we create a corresponding MapGuide ticket for the 
  required Fusion tickets and URL link them, it should give us some more clarity.
<jasonbirch> That makes sense, and a link back from Fusion asking to update on completion.
<bdechant> That would be nice
<jasonbirch> I think a cleanup of the MapGuide trac is most important though.
<trevorw> Just setting the milestone might lead to too much noise unless someone bumps the 
  milestone to 2.2 for all the stuff we are not fixing for the release.  That would be 
  "cleanup".
<jasonbirch> I can go and close a lot of old issues, asking for re-open if still WIP / 
  outstanding.
<jasonbirch> Items should not have a milestone at all unless they are accepted and there 
  are resources assigned.
<bdechant> That would be great Jason - as the tickets need a cleaning
<trevorw> I can also help Jason with the cleaning.
<bdechant> Can we assign an action item to you Jason/Trevor for cleaning up the tickets?
<jasonbirch> I'm was just going to blanket close all issues that are reported at version 
  1.2 (with a note to re-open if still an issue), and ask for retests against 2.1 for 
  items submitted at 2.0.
<jasonbirch> Sure.
<bdechant> Thanks
<bdechant> That makes sense Jason
<jasonbirch> I'm also going to clear the milestone from all tickets, unless they are 
  accepted by someone.
<bdechant> Is there anyway that we could have that field only controllable by the PSC/RM?
<jasonbirch> I don't think so, but not sure how granular Trac permissions are.
<trevorw> This sounds good.  If we cannot control the milestone field, then maybe we add 
  an approved for release field?
<bdechant> Having both might be confusing
<trevorw> Maybe we change milestone to approved for?
<trevorw> But milestone could mean "targeted for".  So maybe we need "target for" and 
  "approved for"?
<trevorw> Developers set targeted for, psc sets approved for?
<bdechant> That makes more sense
<trevorw> Tickets against approved RFCs can set both since approval has already been given.
<jasonbirch> I don't think Trac is that flexible...
<jasonbirch> At least not through the web admin.
<trevorw> This would all be a manual process, assuming we can change "milestone" to 
  "targeted for".
<trevorw> Developers would have to be good and follow the process.
<jasonbirch> Can't.  Milestone, Version, etc are built-in concepts in Trac.
<jasonbirch> But milestone == approved for.
<jasonbirch> Developers are supposed to control acceptance of work.
<jasonbirch> Once it's accepted, should be done in trunk.
<jasonbirch> If there's a branch, need approval to apply to that.
<jasonbirch> Probably just done via mailing list?
<trevorw> Do we need a "trunk" milestone then?
<trevorw> And two separate tickets logged?
<trevorw> Currently, one ticket applies to both streams.
<jasonbirch> I think we're mixing concepts.
<CIA-28> MapGuide: waltweltonlair * r4215 /trunk/MgDev/Common/Renderers/DWFRenderer.cpp: 
  (log message trimmed)
<CIA-28> MapGuide: Fix #1088: Plot to DWF (eplot) - plot incomplete / features missing
<CIA-28> MapGuide: The bug is in DWFRenderer. It generates a W2D resource for each layer 
  in the
<CIA-28> MapGuide: map. There's some optimization code to only generate certain opcodes 
  when style
<CIA-28> MapGuide: information changes from feature to feature. This works fine if you 
  just have
<CIA-28> MapGuide: one layer: the required opcodes are added as part of the first feature 
  and are
<CIA-28> MapGuide: updated as necessary for the layer's remaining features. But if you 
  have more
<jasonbirch> Issues are fixed in trunk.  Once there's a code freeze, issues can only be 
  pulled up to branch on approval from RM.
<trevorw> That sounds right.  How do we get Trac to "track" the approval?
<trevorw> Does trunk have no milestone, then PSC sets milestone?
<jasonbirch> For work in process, the milestone would be set to next release.  After code 
  freeze, only RM can set milestone to branched verison?
<jasonbirch> (current release)
<CIA-28> MapGuide: waltweltonlair * r4216 /trunk/MgDev/Common/Renderers/DWFRenderer.cpp: 
  Fix comment typo
<jasonbirch> Anyway, to move on, how about I post an official Beta using Fusion trunk.
<jasonbirch> Give that a month, and then release 2.1 with whatever the current state is?
<trevorw> That sounds reasonable to me.
<bdechant> Sounds good
<jasonbirch> I don't think there are any core show-stoppers in MapGuide, unless you need 
  to run with fdo connection caching turned on. :)
<kenneth_> Fine by me
<jasonbirch> I'll try to get that done this weekend.
<bdechant> Ok - so can we move on to the next agenda item?
<tomf2> +1
<jasonbirch> Yes.
<tomf2> ...to Jason's proposal
<tomf2> ...and to moving on :)
<bdechant> Next item - Sponsorship RFC83
<tomf2> We're over time
<jasonbirch> I may have to leave soon, but I'm OK with vote on RFC83 as it stands.
<bdechant> Should we vote on RFC83 and then wrap it up?
<tomf2> me too, but was it put out for review?
<jasonbirch> Would need to define process for approving funds expenditure, and appoint 
  someone to track and report to OSGeo
<jasonbirch> I think it was circulated informally.
<bdechant> Ahh right - not offically reviewed yet
<trevorw> It was circulated internally but do we need to get community feedback on it?
<tomf2> yes
<bdechant> They need to be invovled
<jasonbirch> All comms should be via -internals list unless there is a specific reason not 
  to.
<jasonbirch> But, perhaps copy -users on this one too.
<trevorw> Ok.  I will put it out for review.  Do we want to include a funding target in 
  the RFC?  50k, 100k, 200k?
<trevorw> I can check with Frank W on the details for the OSGeo sponsorship mechanism
<CIA-28> MapGuide: NormOlsen * r4217 /trunk/MgDev/Common/ (11 files in 2 dirs):
<CIA-28> MapGuide: This submission can be considered the first complete beta submission 
  for RFC 76.
<CIA-28> MapGuide: It includes all (most all anyway) functionality originally intended by 
  the RFC,
<CIA-28> MapGuide: and most all functionality has been tested, superficially, in a rather 
  sterile
<CIA-28> MapGuide: environment using only the debugger to manually inspect numerical 
  results.
<CIA-28> MapGuide: Surely, once a real application produces graphical results we will have 
  some
<CIA-28> MapGuide: bugs to fix.
<bdechant> ok - so RFC83 will be posted for review
<jasonbirch> How about we hold off on target until we see what kind of response we get?
<bdechant> Do we want to stop here as we are out of time?
<bdechant> I would leave target out
<trevorw> Ok.  Sounds good.  The RFC should generate some list traffic.  Target is out.
<jasonbirch> If someone can take a task to look into CCLA forms?
<jasonbirch> There was one developed in Doc format, and it used to be online,but I can't 
  find it now.
<jasonbirch> And there is no way for employers to grant code submission rights as it 
  stands.
<jasonbirch> A bit problematic.
<bdechant> Indeed
<kenneth_> I posted the CCLA thing, and basically I would like to know how I can get a 
  CCLA. I have done work that I had to scrap because I could not get one.
<kenneth_> And I won't ask my employer to do MapGuide work before I can guarantee that it 
  will can be legally submitted
<kenneth_> I have searched the website, and asked on the mailing list, but no response, so 
  I assume that it never existed, or has gone missing
<tomf2> Never had one for MapGuide
<tomf2> I'm wondering what is going on here at Autodesk now, we all have individual CLAs
<trevorw> I think we were using the standard OSGeo contributor agreement.  I only see the 
  proposal for it posted.  http://wiki.osgeo.org/wiki/Individual_Contributor_License_Agree
  ment_%28CLA%29
<trevorw> Google... http://fdo.osgeo.org/files/Individual%20Contributor%20Agreement%20-%20
  FDO.pdf
<trevorw> Now where's the MapGuide one?
<tomf2> kenneth_ are you saying that the individual CLA is not good enough legally, or is 
  it something that your employer requires?  Either way, we should get the CCLA out; I'll 
  see if Bob can help me (or I can help him) with that.
<jasonbirch> We can steal FDO's
<jasonbirch> And their process for submitting, etc.
<kenneth_> It states that the individual has employers consent. That is a bit odd because 
  I signed mine with regards to the work I had done personally
<tomf2> jasonbirch: what process for submitting?
<kenneth_> tomf2 I would like some signed document from my employer granting me rights to 
  commit work that belongs to him
<kenneth_> I expected that that was what a CCLA is
<kenneth_> that the company accepts that employees submit code to the project
<jasonbirch> Yes, that was the intent.
<tomf2> Here's the FDO one: http://fdo.osgeo.org/files/Corporate%20Contributor%20Agreement
  %20-%20FDO.pdf
<trevorw> I found the one I signed - stock OSGeo agreement - http://mapguide.osgeo.org/fil
  es/Individual%20Contributor%20Agreement.pdf
<trevorw> Bob would probably know for certain but I don't know if the Corporate agreement 
  was every approved.
<tomf2> I believe it is more "the project will accept code from the designated employees 
  of that company"
<kenneth_> The FDO one looks just right, can Tom or Bob post one for MG?
<trevorw> I think the stock OSGeo agreement and the Fdo agreement are basically the same.  
  Just replace OSGeo with Fdo
<tomf2> I have to go
<trevorw> Just to confuse the issue even more, Fdo has posted a corporate contributor 
  agreement as well http://fdo.osgeo.org/files/Corporate%20Contributor%20Agreement%20-%20F
  DO.pdf
* kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) Quit (Remote closed the connection)
<trevorw> Ok.  Are we done for the day?
* kenneth_ (n=chatzill@0x55517824.adsl.cybercity.dk) has joined #mapguide
<tomf2> trevorw see my third from last message
<jasonbirch> I have to go :)
<trevorw> Oops.  Sorry Tom.  Didn't catch the corporate.
<jasonbirch> Basically, CCLA was required, but also needed individuals.
<jasonbirch> Gotta find that doc now...
<jasonbirch> http://lists.osgeo.org/pipermail/fdo-internals/2007-November/001589.html
<jasonbirch> Not sure if that's all...
<trevorw> Ok.  I have three action items listed for the meeting:
<trevorw> 1. Jason/Trevor Clean trac tickets
<trevorw> 2. Jason release beta based on fusion trunk follow by 2.1 release 1 month later
<trevorw> 3. Trevor post RFC 83 for review to -internals and -users.  Talk to Frank W 
  about OSGeo sponsorship mechanism
<jasonbirch> Could Tom / Bob look into porting FDO CCLA to MapGuide?
<trevorw> Both corporate and individual variants?
<jasonbirch> We already have an individual CLA I think.
<tomf2> And I've already said that I would do that? Trevor do you have a filter on my 
  messages! :)
<trevorw> Ok.  Just corporate then.  The individual agreement does not mention Mapguide 
  but that's probably ok.
<jasonbirch> Oh, me too :)
<kenneth_> The last item on the list (RFC #69) should probably be delayed, as it currently 
  depends on FDO RFC #40, unless it should be answered as a prototype question
<kenneth_> trevorw: what is the status for the nightly builds?
<trevorw> For the builds, I would like to migrate the Xen VMs to VMware.  I am planning on 
  moving to a colocation site to do official VMware hosting and would like to use the same 
  infrastructure.  This would also enable me to host a code collaboration tool.  Didn't 
  want to do that one out of my basement.
<bdechant> Sorry had to step out for a meeting
<bdechant> Back now
<trevorw> The builds machines are still there, but the installers have not been integrated 
  into the build process yet.
<kenneth_> Ok, so what would be the plan for getting a link to a nightly build posted on 
  the osgeo websited?
<kenneth_> first move to VMWare, then move hosting systems, then integrate installers, 
  then post link?
<trevorw> Yep.  That's about right.  For the beta, Jason has been doing the builds himself.
<trevorw> Do we want a builds link up sooner than that?  The colocation will probably not 
  happy until the end of the month.
<trevorw> I could move the VMs over and continue hosting out of my basement temporarily.  
  Download bandwidth would be slow though.
<kenneth_> The beta is more important to me than the nightly builds, I just wanted some 
  kind of assurance that the builds are progressing
<trevorw> Having nightly builds available during the beta period might be useful.
<trevorw> Yes.  The builds are progressing.  I have been busy with "groundwork" the last 
  few weeks - colocation negotiations and VMware certification.
<kenneth_> super
<kenneth_> does that conclude the psc meeting?
<bdechant> thanks
<trevorw> Yep.  I will add another action item for the builds.  Thanks everyone
<bdechant> I think that is it
<bdechant> Thanks all
End of #mapguide buffer    Thu Sep 10 13:45:49 2009