MapGuide PSC Meeting 02-01-2007

MapGuide PSC - Home

Meeting Info

The fifth meeting of the MapGuide PSC will take place Thursday February 1st at 18:00 UTC (1:00 PM EST / 11:00 AM MST / 10:00 AM PST).

Meeting Chair:  Bob Bray
Universal Time:  http://www.timeanddate.com/worldclock/fixedtime.html?month=02&day=01&year=2007&hour=18&min=0&sec=0&p1=0
Location:  The meeting will be held on IRC at #mapguide

Agenda

• CLA Collection
• Incubation Status
• Trac Setup, Process, Etc.
• Tweaking Mail List Behavior
• Process to put a minor modification into an already approved RFC. (Tom)

Transcript

<rbray> Ok, lets get started. Not sure where Jason and Tom are but I am sure they will join shortly. <rbray> First topic is CLA collection. We need to get everyone with commit rights to sign and send in a CLA. <rbray> Hey Jason. <pagameba> sorry, stepped out for a sec <jasonbirch> Howdy howdy (just to make you feel at home :) <rbray> I thought I would just post a mail to every commiter and have them fax them in. <rbray> Do we need to set a timeframe for that? <jasonbirch> Yes. <rbray> What do you think a week? <rbray> Else they lose commit rights... <jasonbirch> Is everyone currently available (not off on holiday? <pagameba> danmo: http://mapguide.osgeo.org/trac/ <sigq> Title: Available Projects (at mapguide.osgeo.org) <jasonbirch> I guess reinstating isn't that hard? <jasonbirch> trac.osgeo.org/trac/mapguide should be the URL we're using <rbray> Yes I think everyone is around. If not it is easy to remove and re-instate. <jasonbirch> SAC decided on serv-ce-based URLs, not project-based <rbray> That is correct. <rbray> The trac is not fully configured however. <rbray> Every evening that I have had spare cycles the SVN instance is down <rbray> and trac with it. <jasonbirch> Do you think that SVN might be getting hammered by spiders? <rbray> Although I am almost there. <rbray> No idea. I need to get SAC to look into it more closely. The upgrade was supposed to fix it, but it was dowwn again last night., <bdechant> It seems to go more often then the old system <bdechant> *go down <jasonbirch> I wish I knew more about SVN. Perhaps there is a log that would allow us to trace what's happening. <rbray> Yes it does, not good. <rbray> Me too, but SAC is on it. <rbray> Anyway, back on topic. Is everyone ok with an e-mail and one week deadline for submitting a CLA? <jasonbirch> Seconded, +1 :) <bdechant> +1 <pagameba> +1 <Haris_> +1 <Andy_Morsell> +1 <rbray> Ok, one down. I'll send that out later today. <rbray> Next topic: Incubation Status. <rbray> danmo: are you with us at the moment? <danmo> yup <danmo> I have started reviewing everything <danmo> A few questions came up, the first one was whether we had an active bug tracker... hence my question about trac before the meeting <rbray> That will be in place by the end of this week. <danmo> Will trac be linked from a easy to find user-accessible location when the setup is completed? <rbray> Just need to fiinish the Wiki pages <rbray> Yep, right off the home page. <danmo> Cool <rbray> With anonymous access for ticket submission. <jasonbirch> We'll be restructuring the menu to be more developer-accessible. <jasonbirch> (Links to SVN, Trac, etc) <rbray> The initial rework of the left nav will be done this week too. <rbray> I am really just waiting to flip the switch on Trac. <rbray> Any other incubation concerns so far? <danmo> I think I saw that the old bugs from the CN system won't be ported to Trac? That's too bad <jasonbirch> Yes, it's unfortunate. It would be nice even to pull them into a web page as "historical". <rbray> That is the plan. Just need time to put together a XSLT for the XML. <rbray> There was about 300 defects/enhancements/tasks in the CN system. <danmo> I think we're in very good shape for incubation. Based on the MapGuide Incubation Status page we'd be all set, but I need to check with IncCom for a complete checklist to pass before graduation. pagameba, did you have such a checklist fro previous projects or was it enough to have addressed everything from the status page? <pagameba> thinking ... <pagameba> I thought there was a graduation checklist <pagameba> but I haven't looked in a while <pagameba> checking <danmo> I was hoping there would be one but could not find it this morning... <danmo> There is http://www.osgeo.org/incubator/process/evaluation.html <sigq> Title: Project Evaluation Criteria | OSGeo.org (at www.osgeo.org) <FrankW> There is no incubation checklist per se. <rbray> That is acceptance into incubation. <danmo> yeah, I know <rbray> Sounds like a next step for the Incubation Committee. A checklist would be helpful... <rbray> And provide some consistency.

• FrankW encourages rbray to prepare and submit one for discussion...

<rbray> At any rate, danmo if you come across any issues please send them to the mailing list. <FrankW> I believe in the past it was felt to be redundant, duplicating much of the other material. <rbray> FrankW: Maybe I'll take on a mentor role and do that. <rbray> Any other incubation related questions or comments? <jasonbirch> The current process just points to the template: http://wiki.osgeo.org/index.php/Project_Graduation_Process <sigq> Title: Project Graduation Process - OSGEO (at wiki.osgeo.org) <rbray> There is this: http://wiki.osgeo.org/index.php/Project_Graduation_Checklist <sigq> Title: Project Graduation Checklist - OSGEO (at wiki.osgeo.org) <danmo> Perhaps the status page is the checklist, but then the template should be edited to include things like "does the project have a bug tracker?" I remember this was brought up as an issue with other projects <pagameba> yep, that seems to be all there is <jasonbirch> Just saw that link :) <jasonbirch> We're missing steps 9 and 10, but I don't think that OSGeo supports those directly? Or is MapGuide running under BuildBot already? <jasonbirch> Oops, sorry, not 10. <rbray> 10 is more or less in place. <rbray> There is a full unit test suite. We are also working on a scalability/performance suite. <danmo> I think I'd make 9 optional <rbray> 9 is internal at the moment. <jasonbirch> I prefer "not public" to internal :) <rbray> It would be nice to move that to BuildBot <rbray> Yea, I agree. But these things take time away from fun stuff. <rbray> Like feature development :) <jasonbirch> Once GeoTec is out of the way, I wouldn't mind getting involved in trying to figure out building and packaging automatically. <danmo> FrankW: Do the issues listed in the code provenance review need to have all been resolved before graduation? <rbray> Excellent a volunteer! <pagameba> danmo, I believe we decided that they did need to be resolved <jasonbirch> Since I'm not too helpful with the fun stuff (other than making my wishes clear) :) <pagameba> what are the issues? <danmo> They seem simple on the surface. For instance, FoundationTest.cpp missing header in http://wiki.osgeo.org/index.php/MapGuide_Provenance_Review <sigq> Title: MapGuide Provenance Review - OSGEO (at wiki.osgeo.org) <rbray> Looks like mostly missing LGPL license headers. <rbray> A lot of them in javascript files where we dont want them. <rbray> or html. <TomFukushima> Yes, most of them were HTML and Javascript files <jasonbirch> Are individual license headers required, or even desirable? <danmo> In the FDO code provenance review, there are a couple of mentioned of copyrighted files without mention of the license, e.g. ConvertUTF.cpp/.h and a couple of .xsd <pagameba> no, they are not required <pagameba> in small js files, for instance, we decided that it was acceptable to explicitly decide not to include them <rbray> FDO will be seperate. So that is excluded from MapGuide Incubation. <rbray> It will come formally into incubator once I get MG out. <danmo> But the incubation status doc refers to it ;) <pagameba> so for everything in that list that says 'no', we need to either fix it or say we won't fix it because it isn't required <rbray> Sorry, that was when I was trying to be slick and push it through with MG. <TomFukushima> pagameba: but they should be in large .js files then? <pagameba> its a judgement call ... but I think yes personally <jasonbirch> I think that a "Body of work" license should be all that is required, with headers only where there are exceptions. <rbray> We could just drop a license file into the directory of html/javascript. That would be easy and not burden the code. <pagameba> that works for me <rbray> danmo: I'll remove the FDO references from the MG incubation status page. <danmo> dropping a single license file in the html/js dirs seems to make sense to me too <TomFukushima> What's a "Body of work" license. Anyone have any examples they could send me? <rbray> Frank did not answer, but if my memory is correct all the issues in provence do not need resolution. As long as there are no copyright violations. <FrankW> Well, "outstanding issues" will be reviewed by inccom before approval. <FrankW> The key is to be sure that stuff is well understood and documented. <rbray> I think that was brought up on the incubator mail list at one point. <jasonbirch> It just means that we are asserting the license and copyright on the entire body of work (in a license.txt file) rather than in individual files. <jasonbirch> Unless the individual files contain differing licences/copyrights. <rbray> Ok, we could drop one of those in the tree. <rbray> danmo: Let us know how your review progresses. I'll keep this item on the agenda until we graduate. <danmo> license.txt as a replacement for license on every individual file or in addition to? <FrankW> Hopefully in addition to, but making up for the lack of it in some files (like javascript). <rbray> I would use it as a catch all. No way we are removing all those. <jasonbirch> lol <danmo> I remember reading in one of the incubation docs that a copyright and license ref was required in every file. I was surprised to see this requirement but it seems to have been agreed to by IncCom <rbray> I was one heck of a perl script that put them all in. <rbray> I = it <ChrisGo> any recommendations on a linux distro im not moving very fast on debian ;) <jasonbirch> Bob is a perl script. <rbray> ChrisGo: Fedora works well. <jasonbirch> CentOS will be closest to RH <rbray> We'll have an FGS installer for Linux in a couple months that should make install on any distro much easier. <ChrisGo> i was going to give that another try but the yum package thing was gona be a learning curve <FrankW> Sweet! <rbray> Oh yea, it works great on CentOS too.

• FrankW flees...

<rbray> Shall we move on to the next topic, or do we have more incubation topics? <danmo> Here is the doc that requires the copyright in every .cpp and .h file: FAQ #1 at http://wiki.osgeo.org/index.php/Code_Provenance_Review <sigq> Title: Code Provenance Review - OSGEO (at wiki.osgeo.org) <ChrisGo> the biggest issue i was having was getting java sdk installed being its "non free" <ChrisGo> maybe i wil wiat a month or so and get the new installer and be clueless how it works but happy it works... yeah <rbray> ChrisGo: You are not the only one, I think we will create an opt out for Java. E.g. a PHP only build. <danmo> No more incubation topics from me <rbray> Ok, lets move on to Trac. <rbray> Which is really, really cool software BTW. <jasonbirch> Change in tune from last meeting ;) <rbray> Yea <rbray> I debated having RFCs simply be enhancement tickets, but... <rbray> You can't edit the description after submitting it. So it would not allow for refinement. <rbray> Instead I think we will need to link Enhancements to RFCs and vice versa. <rbray> Make sense? <jasonbirch> I think they need to be a separate status (or WIKI page) that reference appropriate enhancement tickets. <rbray> Right <jasonbirch> Or, in other words, yes. <rbray> We could use the Enhancment ticket to discuss the RFC, but that feels wrong. The mail list is the right place for that. <jasonbirch> Agreed. The RFC should be modified based on discussions in the mailing list. Right tool for the job. <pagameba> I vote for a wiki page for the actual RFC followed by an enhancement ticket when the RFC is approved <jasonbirch> Especially since we're not opening up Wiki rights outside of the PSC/Developer ++ community <pagameba> and discussions on the mailing list <rbray> Could happen the other way. <rbray> If a user requests an enhanment via a ticket, that then turns into an RFC. <rbray> For example. <jasonbirch> enhancement-> Wiki RFC -> Task <rbray> Don't need the task really do you? <jasonbirch> Yes, need it to track SVN commits for the RFC against. <rbray> Why not use the Enhancement? <jasonbirch> Might be many-> one between enhancements and RFC <rbray> I can buy that, just more tickets to manage though. <jasonbirch> Yes, but easier to track back from commits to RFC <rbray> Any objections to this approach? <rbray> If not then I'll document it on the Trac Wiki. <jasonbirch> Enhancement tickets should be closed as soon as fully integrated into RFC. <rbray> BTW: you can see trac in its current state at: http://www.osgeo.org/trac/mapguide <sigq> Title: MapGuide Open Source - Trac (at www.osgeo.org) <jasonbirch> RFC status (and associated task) are closed when code is complete <rbray> And all related enhancements... <TomFukushima> we should only close Enhancement when the RFC has been completed; RFC could always be withdrawn at some point <jasonbirch> No, I think enhancements should be closed as soon as RFC is adopted. <ChrisGo> rbray: you should do a web cast on linux ;-) <jasonbirch> Oh. <ChrisGo> I will even donate a few cases of your choice beer. <rbray> Excellent. <jasonbirch> ChrisGo: Individually shipped to the participants? <TomFukushima> I guess we could reopen the enhancement if the RFC is withdrawn <jasonbirch> I'd prefer that... <ChrisGo> I'be installed NetBSD, Fedora and Debian and once I get to the install package something always goes wrong ;X <rbray> How often do you think we would withdraw an RFC? <jasonbirch> I don't think that we even account for that in the process once it's adopted. <rbray> We dont at the moment. <rbray> ChrisGo: What version of Fedora? <jasonbirch> Let's hope it's a rare event. The process is supposed to confirm "rightness" and "commitment" <rbray> I agree. So lets go forth with enhancements are closed when the RFC is adopted. <rbray> Should probably be final RFC. Might take more than one for some enahancement requests. <rbray> Like the ones you ask for Jason :) <jasonbirch> Yes, don't close them unless they are fully implemented in the RFC. Add a note to the enhancement saying "partially implemented in RFC# / task# <rbray> Ok, I'll document that stuff on the new Wiki. Give me a day or so. <jasonbirch> Heh... <jasonbirch> ok. I have a meeting in 4 mins... :) <rbray> Last item on Trac, any suggestions for extra fields? <rbray> Not really sure we need any, although I did bring back Severity and Priority. <jasonbirch> Can we carry that over to email once have had time to look at current setup? <rbray> Of course. <rbray> I only added one field, External ID. Gee wonder what that is for... <jasonbirch> I don't want to know... <jasonbirch> Mailing list: can we please turn off HTML email on the lists, and restrict attachments to text, jpg, png, gif? <rbray> Yes, I'll try that again. <rbray> Did not work so well last time. Maybe I'll enlist Shawns help./ <jasonbirch> It's working on the WebCom list. Let me know if you want me to take over list admin. <rbray> Sure. I'll send you the password by e-mail. <jasonbirch> I gotta go... good meeting. see you next week and in email. <ChrisGo> its really nice to see so many leads in irc <rbray> Ok, we are out of time. All remaining topics go to the next meeting agenda. <rbray> Thanks everyone... <TomFukushima> bye <jasonbirch> Someone gonna grab the logs?