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 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?