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
Ok, lets get started. Not sure where Jason and Tom are but I am sure they will join shortly. First topic is CLA collection. We need to get everyone with commit rights to sign and send in a CLA. Hey Jason. sorry, stepped out for a sec Howdy howdy (just to make you feel at home :) I thought I would just post a mail to every commiter and have them fax them in. Do we need to set a timeframe for that? Yes. What do you think a week? Else they lose commit rights... Is everyone currently available (not off on holiday? 	danmo: http://mapguide.osgeo.org/trac/ 	Title: Available Projects (at mapguide.osgeo.org) 	I guess reinstating isn't that hard? 	trac.osgeo.org/trac/mapguide should be the URL we're using 	Yes I think everyone is around. If not it is easy to remove and re-instate. 	SAC decided on serv-ce-based URLs, not project-based 	That is correct. 	The trac is not fully configured however. 	Every evening that I have had spare cycles the SVN instance is down 	and trac with it. 	Do you think that SVN might be getting hammered by spiders? 	Although I am almost there. 	No idea. I need to get SAC to look into it more closely. The upgrade was supposed to fix it, but it was down again last night., 	It seems to go more often then the old system 	*go down 	I wish I knew more about SVN. Perhaps there is a log that would allow us to trace what's happening. Yes it does, not good. Me too, but SAC is on it. Anyway, back on topic. Is everyone ok with an e-mail and one week deadline for submitting a CLA? Seconded, +1 :) 	+1 	+1 	+1 	+1 	Ok, one down. I'll send that out later today. 	Next topic: Incubation Status. 	danmo: are you with us at the moment? 	yup 	I have started reviewing everything 	A few questions came up, the first one was whether we had an active bug tracker... hence my question about trac before the meeting 	That will be in place by the end of this week. 	Will trac be linked from a easy to find user-accessible location when the setup is completed? 	Just need to finish the Wiki pages 	Yep, right off the home page. 	Cool 	With anonymous access for ticket submission. 	We'll be restructuring the menu to be more developer-accessible. 	(Links to SVN, Trac, etc) 	The initial rework of the left nav will be done this week too. 	I am really just waiting to flip the switch on Trac. 	Any other incubation concerns so far? 	I think I saw that the old bugs from the CN system won't be ported to Trac? That's too bad Yes, it's unfortunate. It would be nice even to pull them into a web page as "historical". That is the plan. Just need time to put together a XSLT for the XML. There was about 300 defects/enhancements/tasks in the CN system. 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? thinking ... I thought there was a graduation checklist but I haven't looked in a while checking I was hoping there would be one but could not find it this morning... There is http://www.osgeo.org/incubator/process/evaluation.html Title: Project Evaluation Criteria | OSGeo.org (at www.osgeo.org) 	There is no incubation checklist per se. That is acceptance into incubation. yeah, I know Sounds like a next step for the Incubation Committee. A checklist would be helpful... And provide some consistency. 	encourages rbray to prepare and submit one for discussion... At any rate, danmo if you come across any issues please send them to the mailing list. 	I believe in the past it was felt to be redundant, duplicating much of the other material. FrankW: Maybe I'll take on a mentor role and do that. Any other incubation related questions or comments? The current process just points to the template: http://wiki.osgeo.org/index.php/Project_Graduation_Process Title: Project Graduation Process - OSGEO (at wiki.osgeo.org) There is this: http://wiki.osgeo.org/index.php/Project_Graduation_Checklist Title: Project Graduation Checklist - OSGEO (at wiki.osgeo.org) 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 yep, that seems to be all there is 	Just saw that link :) 	We're missing steps 9 and 10, but I don't think that OSGeo supports those directly? Or is MapGuide running under BuildBot already? 	Oops, sorry, not 10. 	10 is more or less in place. 	There is a full unit test suite. We are also working on a scalability/performance suite. 	I think I'd make 9 optional 	9 is internal at the moment. 	I prefer "not public" to internal :) It would be nice to move that to BuildBot Yea, I agree. But these things take time away from fun stuff. Like feature development :) 	Once GeoTec is out of the way, I wouldn't mind getting involved in trying to figure out building and packaging automatically. 	FrankW: Do the issues listed in the code provenance review need to have all been resolved before graduation? 	Excellent a volunteer! 	danmo, I believe we decided that they did need to be resolved 	Since I'm not too helpful with the fun stuff (other than making my wishes clear) :) what are the issues? They seem simple on the surface. For instance, FoundationTest.cpp missing header in http://wiki.osgeo.org/index.php/MapGuide_Provenance_Review Title: MapGuide Provenance Review - OSGEO (at wiki.osgeo.org) Looks like mostly missing LGPL license headers. A lot of them in javascript files where we dont want them. or html. 	Yes, most of them were HTML and Javascript files Are individual license headers required, or even desirable? 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 no, they are not required in small js files, for instance, we decided that it was acceptable to explicitly decide not to include them FDO will be seperate. So that is excluded from MapGuide Incubation. It will come formally into incubator once I get MG out. But the incubation status doc refers to it ;) 	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 	Sorry, that was when I was trying to be slick and push it through with MG. 	pagameba: but they should be in large .js files then? 	its a judgement call ... but I think yes personally 	I think that a "Body of work" license should be all that is required, with headers only where there are exceptions. 	We could just drop a license file into the directory of html/javascript. That would be easy and not burden the code. 	that works for me 	danmo: I'll remove the FDO references from the MG incubation status page. 	dropping a single license file in the html/js dirs seems to make sense to me too 	What's a "Body of work" license. Anyone have any examples they could send me? 	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. 	Well, "outstanding issues" will be reviewed by inccom before approval. 	The key is to be sure that stuff is well understood and documented. I think that was brought up on the incubator mail list at one point. 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. Unless the individual files contain differing licences/copyrights. Ok, we could drop one of those in the tree. danmo: Let us know how your review progresses. I'll keep this item on the agenda until we graduate. license.txt as a replacement for license on every individual file or in addition to? 	Hopefully in addition to, but making up for the lack of it in some files (like javascript). I would use it as a catch all. No way we are removing all those. lol 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 I was one heck of a perl script that put them all in. I = it 	any recommendations on a linux distro im not moving very fast on debian ;) 	Bob is a perl script. 	ChrisGo: Fedora works well. 	CentOS will be closest to RH 	We'll have an FGS installer for Linux in a couple months that should make install on any distro much easier. 	i was going to give that another try but the yum package thing was gona be a learning curve 	Sweet! 	Oh yea, it works great on CentOS too. 	flees... 	Shall we move on to the next topic, or do we have more incubation topics? 	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 	Title: Code Provenance Review - OSGEO (at wiki.osgeo.org) 	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 ChrisGo: You are not the only one, I think we will create an opt out for Java. E.g. a PHP only build. No more incubation topics from me Ok, lets move on to Trac. Which is really, really cool software BTW. Change in tune from last meeting ;) 	Yea 	I debated having RFCs simply be enhancement tickets, but... 	You can't edit the description after submitting it. So it would not allow for refinement. 	Instead I think we will need to link Enhancements to RFCs and vice versa. 	Make sense? 	I think they need to be a separate status (or WIKI page) that reference appropriate enhancement tickets. 	Right 	Or, in other words, yes. 	We could use the Enhancment ticket to discuss the RFC, but that feels wrong. The mail list is the right place for that. 	Agreed. The RFC should be modified based on discussions in the mailing list. Right tool for the job. 	I vote for a wiki page for the actual RFC followed by an enhancement ticket when the RFC is approved 	Especially since we're not opening up Wiki rights outside of the PSC/Developer ++ community 	and discussions on the mailing list 	Could happen the other way. If a user requests an enhanment via a ticket, that then turns into an RFC. For example. enhancement-> Wiki RFC -> Task Don't need the task really do you? Yes, need it to track SVN commits for the RFC against. Why not use the Enhancement? Might be many-> one between enhancements and RFC I can buy that, just more tickets to manage though. Yes, but easier to track back from commits to RFC Any objections to this approach? If not then I'll document it on the Trac Wiki. Enhancement tickets should be closed as soon as fully integrated into RFC. BTW: you can see trac in its current state at: http://www.osgeo.org/trac/mapguide Title: MapGuide Open Source - Trac (at www.osgeo.org) RFC status (and associated task) are closed when code is complete And all related enhancements... <TomFukushima>	we should only close Enhancement when the RFC has been completed; RFC could always be withdrawn at some point No, I think enhancements should be closed as soon as RFC is adopted. <ChrisGo>	rbray: you should do a web cast on linux ;-) 	Oh. <ChrisGo>	I will even donate a few cases of your choice beer. 	Excellent. 	ChrisGo: Individually shipped to the participants? <TomFukushima>	I guess we could reopen the enhancement if the RFC is withdrawn 	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 	How often do you think we would withdraw an RFC? 	I don't think that we even account for that in the process once it's adopted. 	We dont at the moment. 	ChrisGo: What version of Fedora? 	Let's hope it's a rare event. The process is supposed to confirm "rightness" and "commitment" 	I agree. So lets go forth with enhancements are closed when the RFC is adopted. 	Should probably be final RFC. Might take more than one for some enahancement requests. 	Like the ones you ask for Jason :) 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# 	Ok, I'll document that stuff on the new Wiki. Give me a day or so. 	Heh... 	ok. I have a meeting in 4 mins... :) 	Last item on Trac, any suggestions for extra fields? 	Not really sure we need any, although I did bring back Severity and Priority. 	Can we carry that over to email once have had time to look at current setup? 	Of course. 	I only added one field, External ID. Gee wonder what that is for... 	I don't want to know... 	Mailing list: can we please turn off HTML email on the lists, and restrict attachments to text, jpg, png, gif? 	Yes, I'll try that again. 	Did not work so well last time. Maybe I'll enlist Shawns help./ 	It's working on the WebCom list. Let me know if you want me to take over list admin. 	Sure. I'll send you the password by e-mail. 	I gotta go... good meeting. see you next week and in email. <ChrisGo>	its really nice to see so many leads in irc Ok, we are out of time. All remaining topics go to the next meeting agenda. Thanks everyone... <TomFukushima>	bye Someone gonna grab the logs?