wiki:PscMeeting03-05-2009

Version 7 (modified by brucedechant, 15 years ago) ( diff )

--

Project Steering Committee - Home

Meeting Info

This meeting of the MapGuide PSC will take place Thursday, March 5, 2009 at 19:00 UTC (2:00 PM ET / noon MT / 11:00 AM PT).

Meeting Chair: Bob Bray

Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=3&day=5&year=2009&hour=12&min=0&sec=0&p1=55

Location: The meeting will be held on IRC at #mapguide

Agenda

  • Appoint a Meeting Secretary
  • Updates on Actions from the Last Meeting
  • Process for voting in new committers. Tom
  • 2.1 beta. Tom
  • ACE 5.6 - Bruce
  • Others?

Minutes

PSC Members present: Andy, Bob, Bruce, Jason, Kenneth, Tom.

Review last meeting's action items

Bob, Bruce, others: Review http://www.jasonbirch.com/nodes/2009/01/31/269/mapguide-rest-extension-feedback-wanted/ by Feb 13, 2009

This one we've reviewed as much as we can, waiting for more details from Harris/Jason.

Paul: Fusion 2.0 beta

It's out.

Paul + Tom: integration of Fusion 2.0 beta into MGOS in time for MGOS 2.1

We've integrated.

Jason + Kenneth - beta installer by end Feb

jng has been making good progress on this. I got the installer running last night, but Apache would crash when I hit the mapagent. And still had to manually configure httpd.conf, php.ini, webconfig.ini. It's definitely getting there though.

Installer

  • Still being worked on
  • Maybe a few more weeks

Process for voting new committers

  • Producing OSS book mentioned that voting and recommending new committers should be done in private in case they are rejected, then they won't be hurt in public.
  • Left as open for the time being as we have few committers and don't want to discourage new committers

2.1 Beta

  • Another couple of weeks.
  • Move the release date on the milestone page out by 2 weeks

ACE 5.6

  • Contains needed 64bit fixes
  • Needs RFC
  • Update for 2.2 release

64bit Support

  • 2.2 Release
  • Need to build 64bit Apache/PHP on Windows
  • Might be able to just support IIS and then only require 64bit PHP

www folder in SVN

  • Delete it

End of meeting

Full transcript

	<rbray>	I am going to give folks another minute or two before we start
	<jasonbirch>	Howdy all. My attention is a bit limited right now, but I'll try to follow along.
	-->|	amorsell (n=chatzill@216-115-120-64.gvea.com) has joined #mapguide
	<rbray>	<jasonbirch> What? Your A.D.D. worse than usual?
	<jasonbirch>	No. unfortunately, it's always this bad...
	<jasonbirch>	but more distractions than usual right now.
	<rbray>	Yea you are not the only one
	<rbray>	Let's go ahead and start it looks like we have enough
	<rbray>	Who can volunteer to take minutes today?
	<rbray>	Thanks Bruce - good of you to volunteer!
	<bdechant>	Nice
	<bdechant>	:)
	<rbray>	Sorry but I have a short timeout
	<rbray>	Update on Actions from Last Meeting
	<bdechant>	That's fine I was going to colunteer anyways :)
	<bdechant>	*volunteer
	<rbray>	First one is mine: "document initial process for donations, usage guidelines etc."
	<rbray>	no progress yet, should stay on the list
	<rbray>	Next one: "Bob, Bruce, others: Review http://www.jasonbirch.com/nodes/2009/01/31/269/mapguide-rest-extension-feedback-wanted/ by Feb 13, 2009"
	<rbray>	This one we've reviewed as much as we can, waiting for more details from Harris/Jason
	<rbray>	Jason - any updates on the state of the REST implementation?
	<jasonbirch>	No code yet. Haris got hijacked by "real" work. May be delayed a bit.
	<rbray>	ok - thanks. Keep us posted
	<rbray>	Next one: "Paul: Fusion 2.0 beta"
	<jasonbirch>	It's out...
	<rbray>	So then Tom, "Paul + Tom: integration of Fusion 2.0 beta into MGOS in time for MGOS 2.1"
	<tomf2>	we've integrated
	<rbray>	so then the last one: "Jason + Kenneth - beta installer by end Feb"
	<jasonbirch>	jng has been making good progress on this.
	<rbray>	I've seen lot's of e-mails so that is promising
	<jasonbirch>	I got the installer running last night, but Apache would crash when I hit the mapagent.
	<jasonbirch>	And still had to manually configure httpd.conf, php.ini, webconfig.ini.
	<jasonbirch>	It's definitely getting there though.
	<jasonbirch>	Thank goodness for Jackie :)
	<rbray>	Good, so maybe another couple of weeks?
	<ksgeograf>	I have looked at the WiX IIS integration, and it's not overly well documented, so I'm not sure we can reach the goal of a fully Wix base IIS installer
	<jasonbirch>	ksgeograph; have you looked at reverse-engineering a website using dark.exe?
	<ksgeograf>	no, I have only read about it
	<jasonbirch>	graf... jeepers.
	<ksgeograf>	but good idea, I will try that
	<tomf2>	Are there instructions somewhere on how to build the code and installers? I'd like to give it a try if I get a chance. Sounds like Jackie has created a nice bat file to do this
	<jasonbirch>	On Jackie's blog.
	<jasonbirch>	just a sec...
	<jasonbirch>	http://themapguyde.blogspot.com/2009/03/building-mapguide-on-windows-made.html
	<ksgeograf>	I'm trying it out now, it seems to be a *lot* easier to build it now
	<jasonbirch>	It's missing a step (the Maestro batch file that copies resources into build dir)
	<jasonbirch>	But yes, it makes compiling MapGuide on Windows insanely easier.
	<tomf2>	thanks
	<rbray>	awesome - thanks Jason, Kenneth, and Jackie!
	<rbray>	Tom, you are next on the agenda - Process for voting new committers
	<jasonbirch>	Hint... Scroll to the bottom for quick steps :)
	<tomf2>	Yes, very nice! thanks for your efforts
	<tomf2>	I read in the Producing OSS book I think that voting new committers in should be done in private
	<tomf2>	in case we reject someone, then they won't be hurt, I think was the main reason
	<jasonbirch>	Hmm.
	<jasonbirch>	Could do that I guess.
	<jasonbirch>	Proposing also, I guess?
	<tomf2>	yeah, that was all I had on this topic.
	<rbray>	Feels odd to do a private vote for some reason
	<jasonbirch>	To me also.
	<jasonbirch>	Are you worried about excessive number of commiters?
	<rbray>	There is potential for bad feelings in that approach too
	<tomf2>	No not at all
	<rbray>	and of course vote fraud - lol
	<tomf2>	No one would ever know if they were being considered for committer or not, so how would there be bad feelings?
	<jasonbirch>	Perhaps change process so that only PSC can nom committers?
	<jasonbirch>	Because right now, any committer can nominate.
	<jasonbirch>	Hmm. Technically, I nominated myself illegally...
	<rbray>	thats it - revoke his commit rights!
	<bdechant>	on it :)
	<ksgeograf>	I read that manual once. it's written by someone from Collabnet, and they have great experience
	<jasonbirch>	that was easier than I expected :)
	<tomf2>	OK, well, since we are still quite open to new committers (i.e., our bar is obviously low :)) perhaps we can revisit this later
	<rbray>	yes it was my blueprint for MGOS
	<jasonbirch>	Hey, I represent that rempark...
	<rbray>	Here is the thing
	<bdechant>	Since we have so few committers at this time I agree we should postpone it
	<rbray>	We need committers
	<rbray>	And people to nominate them
	<jasonbirch>	I think the number of different people contributing to Maestro is cool.
	<rbray>	So I am not currently in favor of limiting nominations or anything else
	<jasonbirch>	And fact that we see someone else proposing viable RFC is awesome.
	<jasonbirch>	Similar pick up on FDO.
	<rbray>	Exactly
	<jasonbirch>	Perhaps starting to mature a bit.
	<tomf2>	Re: nomination, I wish I had my book because going on my memory sucks, anyone can nominate someone but that is also supposed to be done in private, and the discussion is supposed to be private among current committers as opposed to the PSC
	<rbray>	YEa that sounds right
	<rbray>	hang on - I have the book
	<jasonbirch>	Let's leave it open for now. If we get more picky (require certain number of good patches, etc) can change in future.
	<ksgeograf>	I found the book online at some time
	<jasonbirch>	If you're worried about me nomming someone who doesn't write good code, then I'll refrain from nomming :)
	<jasonbirch>	Yes, book is Free.
	<ksgeograf>	If someone is nominated publicly, others will be less likely to say no, even if they have valid reasons for doing so
	<rbray>	Let's leave this as is for now.
	<ksgeograf>	But currently, I think the number of possible comitters is so low that it is not a problem
	<rbray>	Yep
	<rbray>	Next item is also Tom: 2.1 Beta
	<jasonbirch>	Already discussed?
	<tomf2>	I got my answer. Another couple of weeks.
	<ksgeograf>	Found it: http://producingoss.com/
	<rbray>	That is what I thought - but I wanted to confirm
	<tomf2>	I'll move the release date on the milestone page out by 2 weeks
	<rbray>	ksgeograf: Yes that is it. Great book.
	<rbray>	Ok then, last formal item belongs to Bruce: ACE 5.6
	<tomf2>	April 2 -> April 16
	<rbray>	ok - thanks Tom
	<bdechant>	I wanted to bring up ACE 5.6 for 2.2 and not for 2.1 - just to clarify
	<bdechant>	The main reason is that ACE 5.6 has lots of 64bit fixes
	<rbray>	So with that you are going to support 64 bit builds?
	<bdechant>	I have a working 64bit MapGuide Server and web tier and ACE 5.6 has been very stable
	<rbray>	nice
	<bdechant>	The project files for the server and some of the web have been updated with x64 targets
	<bdechant>	There are still some issues left
	<rbray>	Sounds like you are advocating that we should put it on the roadmap for 2.2 though
	<bdechant>	I can go into details as there are really only 2 items :)
	<tomf2>	Do we do RFCs for these upgrades, or do we just do them?
	<bdechant>	Yes!
	<bdechant>	RFC - I can take care of that after 2.1
	<rbray>	I suggest an RFC for the update to ACE 5.6
	<tomf2>	You don't have to wait for 2.1, you could create an RFC with a 2.2 target
	<bdechant>	That's what I meant :)
	<rbray>	Out of curiosity - what are the two remaining issues?
	<tomf2>	np
	<tomf2>	oops, ignore that
	<bdechant>	1) Reader ID used by web/server is a raw 32bit pointer - BAD. This will be changed to a lookup table and remove the raw pointer
	<bdechant>	2) Apache/PHP - we need to build a 64bit version. There is a project out there that was doing it, but they stopped over a year ago.
	<bdechant>	I am using the older version of this 64 bit Apache/PHP
	<rbray>	there is no 64 bit build of Apache - you have to be kidding me
	<jasonbirch>	Is that only on Windows?
	<bdechant>	Not kidding - I was disappointed
	<bdechant>	I have only investigated it on Windows - so I'm not sure about Linux
	<rbray>	for Linux you always build it, so I am sure it has 64 bit build options
	<jasonbirch>	I think so too.
	<bdechant>	That would be my guess
	<rbray>	ok - neither of those seem like showstoppers
	<jasonbirch>	I don't think it would be unreasonable to only support IIS on 64bit Windows.
	<tomf2>	I bet Jackie could build us a 64-bit version for Windows :)
	<ksgeograf>	yeah, it would take him like 30 min
	<bdechant>	We still need 64bit PHP on windows even with IIS
	<jasonbirch>	Oh crap :)
	<rbray>	ok, so when is that 2.2 beta with 64 bit support?
	<tomf2>	Are you asking if we can get it at the same time as the 2.2 beta with 32-bit support?
	<jasonbirch>	Is there consideration being given to upgrading Apache and PHP?
	<jasonbirch>	Or GEOS, or...
	<jasonbirch>	:)
	<rbray>	I am just pushing
	<rbray>	We should evaluate other component upgrades as well - for 2.2
	<tomf2>	Currently, we have 2.2 scheduled for Oct 1. The only item in it is 64-bit support currently.
	<bdechant>	If we can get someone to do the 64bit Apache/PHP work - I'm sure it could be in the 2.2 beta :)
	<tomf2>	Shall we shoot for August for the beta?
	<rbray>	Sure
	<rbray>	Let's put 2.2 on our agenda for next time
	<rbray>	64bit support and color palette support in that release would be cool
	<rbray>	Any other items for today?
	<tomf2>	UV is targeting color palette support for 2.1
	<rbray>	Not if resource definitions are changing
	<rbray>	Which I saw in some of the recommendations
	<rbray>	Depends what it looks like in the end
	<tomf2>	yes
	<rbray>	It seems a little late in the game to add a new resource type and change MapDefinition
	<rbray>	so that is why I figured 2.2
	<bdechant>	Agreed
	<tomf2>	yeah, if it doesn't make 2.1 we'll move it to 2.2
	<rbray>	Anyway we'll see how hte RFC discussion on that plays out
	<rbray>	other topics for today?
	<rbray>	going once...
	<jasonbirch>	I
	<jasonbirch>	Was thinking that it would be resource data, not resource definition
	<jasonbirch>	?
	<rbray>	Really?
	<jasonbirch>	Oh, it was Tom? who suggested making it its own resource type.
	<rbray>	Then it could make 2.1 possibly
	<jasonbirch>	If he codes fast :)
	<bdechant>	The discussion on RFC60 isn't finished yet
	<tomf2>	Not me, I haven't been involved in this discussion yet
	<jasonbirch>	Must have been Bruce then :)
	<bdechant>	I believe it was me that suggested it
	<tomf2>	I have one more item
	<jasonbirch>	No, it's not over yet. I think that there was some confusion on my comments.
	<rbray>	ok
	<tomf2>	I just noticed that there is still a www directory in the MgDev vault. Can we delete that too?
	<tomf2>	We recently delete WebStudio. I think that everyone knows that.
	<jasonbirch>	Where is the www directory?
	<ksgeograf>	if you check out mapguide/trunk/
	<ksgeograf>	is there in the root folder
	<jasonbirch>	Right, not in MgDev though.
	<tomf2>	and it takes a long time to download when I get trunk
	<bdechant>	correct
	<jasonbirch>	I never grab trunk directly; always separate co on MgDev, Installer, etc...
	<tomf2>	I know, if I was smart I wouldn't download it
	<jasonbirch>	Is www used for anyhting?
	<tomf2>	But, I don't really know what the purpose of this directory is for
	<jasonbirch>	Automated update of static Drupal resources?
	<jasonbirch>	If not, it could probably be dumped.
	<tomf2>	We update the web API docs using webdav now
	<jasonbirch>	It looks a lot like the old collabnet notation for multilang.
	<jasonbirch>	And no updates in over two years.
	<jasonbirch>	I'd wager that it's relatively save to remove.
	<jasonbirch>	Delete it, and then roll back if something breaks? :)
	<rbray>	yea I think it can go
	<tomf2>	lol, who gave Jason commit rights :)
	<tomf2>	OK, thanks, I'll delete it
	<jasonbirch>	Hmm. Too footloose and fancy free for this crowd...
	<tomf2>	Oh yeah, I gave him the commit rights, never mind
	<jasonbirch>	I think we're done?
	<rbray>	Yep
	<rbray>	Thanks everyone
	<bdechant>	Thanks all
	<tomf2>	bye
	<jasonbirch>	thx. gonna give Haris heck for missing this meeting :)
Note: See TracWiki for help on using the wiki.