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)
== Actions ==
== 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 down 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 finish 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?