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