Project Steering Committee - Home

Meeting Info

The first meeting of the FDO PSC will take place Monday October 30 at 9:00 AM (UTC/GMT-7) / 11:00 AM (UTC/GMT-5) / 5:00 PM (UTC/GMT+1).

Meeting Chair: Bob Bray Universal Time: ​http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=10&day=30&hour=16&min=0&sec=0 Location: The meeting will be held on IRC at ​#fdo

For IRC newbies Chatzilla is probably the best way to get going. It works with Firefox and once installed you can log onto the channel by pointing your browser at: ​irc://irc.freenode.net/#mapguide. You can download Chatzilla from: ​http://www.hacksrus.com/~ginda/chatzilla/.

Agenda

• Review PSC Document - ​https://fdo.osgeo.org/psc.html
• Development and/or PSC Meetings on IRC
• Initial PSC size and member nominations
• Next Steps / PSC Tasks

Minutes

PSC Members Present: Bob, Greg, Orest, Mateusz, Frank

• PSC Guidelines Discussion
• Change to clarify that significant decisions are to happen via e-mail while minor ad-hoc decisions may happen via IRC.
• Change IRC veto to 48 hours after the minutes are posted and e-mail notification sent to account for time zones.
• Clarify what happens after an e-mail veto.
• Broaden Process item 11 to give the chair authority to extend voting periods, etc.
• Open discussion around RFCs to be continued next meeting. Statement that all FDO feature development both internal and external will be RFC driven.
• Open disucssion of branch strategies, with a general consensus that we should branch as "late as possible".
• Deemed a need for a documented development process, including the branch strategy.
• PSC meetings will be held by IRC until it is running smoothly ~ 4 weeks for now.
• Dev meetings via IRC to be held if the PSC and developers feel it is required.

Actions

• (Bob) Update the PSC Guidelines and motion to approve via e-mail.
• (Bob) Create a task list on the WIKI.

Transcript

 <<rbray>>	Welcome everyone, I am just going to give Frank a moment or two to see if he joins before we begin.
 <<rbray>>	Did everyone have a chance to read the PSC guidelines?
 <gboone>	yES
 <orest>	Yes
 <<rbray>>	Frank had one comment posted to the mailing list to clarify e-mail vs. IRC voting. Any other comments, reactions, etc?
 <orest>	Question: For a motion to be made at an IRC meeting, does it have to be posted ahead of time to give members a chance to review it? 
 <mloskot>	good morning
 <<rbray>>	Hi mloskot. Good evening over there isn't it?
 <mloskot>	yup
 <<rbray>>	<orest>: Not necesessarily. IRC motions and voting are more for ad-hoc type decisions.
 <<rbray>>	This doesn't really concern me because of the veto with 24 hour rule.
 <<rbray>>	So for example near releases we may use IRC to decide whether to fix bug XYZ or not. That would not really need a motion on e-mail.
 <rbray>	Does that make sense?
 <orest>	If a member misses a meeting and an IRC vote, how will they be informed that a vote happened? By reading the minutes?
 <rbray>	Yes. Meeting minutes will always be posted and e-mailed. The 24 hour veto period begins when the e-mail is posted.
 <rbray>	The change that I plan to make call for all significant decisions to happen via e-mail. That way everyone has a better chance to participate and there is a permanent record.
 <gboone>	Sounds reasonable
 <mloskot>	for me too
 <orest>	OK. The doc says email votes need at least two working days and preferably one week.
 <orest>	Maybe veto against an IRC vote also should be at least two working days?
<rbray>		Yes that is correct. Sure we can make it 48 hours. What does everyone else think?
 <gboone>	Sure
 <mloskot>	Sure
 <rbray>	It needs to be short, certainly no more than 48 hours. Otherwise we'll be rolling out commits.
 <mloskot>	24 hours may be too short taking time zones into account :-)
 <mloskot>	but 48 is certainly enough.
 <rbray>	That is true. I think this came from the MG PSC prior to Harris joining.
 <rbray>	Everyone else in that PSC is in North America.
 <mloskot>	Right.
<rbray>		So I'll make that change as well. Any other comments on the PSC document?
<FrankW>	arrives very sheepishly.
 <rbray>	Hi FrankW.
 <rbray>	No worries. Just collecting other comments on the PSC document. So far the one additional item is pushing the veto on IRC decisions to 48 hours to account for timezones.
 <rbray>	We also clarified your e-mail, re: major decisions should happen via e-mail, and only ad-hoc decisions on IRC.
 <FrankW>	ok
 <rbray>	So back to my question, any other comments on the PSC guidelines?
 <mloskot>	May be it's worth to say a word about what happen if one of us will send his veto
 <mloskot>	next IRC meeting to discuss details or continuing by e-mail?
 <rbray>	Hmm, good question. I think it means discussion continues via e-mail. All vetos require a reason, which I am sure would provoke some discussion.
 <rbray>	I assume the motion would be adjusted and go back to vote (or be dropped if the argument was a good one :) )
 <mloskot>	ok, it's clear.
 <mloskot>	My question was related to Process, 8)
 <mloskot>	from PSC DRAFT
 <rbray>	Yea, I think it should probably be clarified in the document too. I can add something to that affect.
 <mloskot>	ok, thanks.
 <rbray>	Ok, so far three recommended changes. Any others?
 <FrankW>	I wonder if we might broaden item "11" in process to indicate that chair has substantial latitude to hold a vote open if needed to achieve consensus.
 <FrankW>	I think it is better to give the chair some liberty rather than having a very details oriented process.
 <gboone>	Agreed
 <mloskot>	+1
 <rbray>	Sorry had to go read 11. Bad considering I wrote this. +1 from me
 <orest>	+1
 <FrankW>	Cool, thanks. I'm thinking of retrofitting something to this effect in gdal psc doc. It is how I have treated my "chair" role for stuff like the incubator.
 <rbray>	Out of curiosity does that come from experience?
 <FrankW>	ie. extending votes if I think it hasn't really been considered, etc.
 <gboone>	Regarding RFC's. Should the requirement to use RFC be instituted immediately?
 <mloskot>	is also interested in discussing RFC part next.
 <rbray>	Right. Really the chair should have broad authority to make sure decisions are made in the best interest of the project. This could be extending deadlines or asking for clarification, or etc.
 <FrankW>	gboone: I think it would be helpful, if only to more publically document some of the changes going into 3.2.
 <FrankW>	And definately for process oriented stuff, like establishing coding guidelines, etc.
 <rbray>	FrankW: You mean the RFC?
 <rbray>	Or the Chair?
 <FrankW>	rbray: I meant to answer Greg's RFC question.
 <rbray>	OK, let's move on to RFCs then,
 <gboone>	We had a number of changes for 3.2 that did not use the RFC process. We continue to make such changes in our 3.2 branch. Does moving them to the trunk require an RFC?
 <rbray>	Yes I think it would be good to start using RFCs immediately. Even for some things already in 3.2.
 <gboone>	Does adding changes to a branch require an RFC?
 <rbray>	Adding a feature or API change requires an RFC. The RFC should declare where it is going branch, trunk, etc.
 <mloskot>	I think we can vote on it, but I also understand starting with RFC now will likely affect current development process Greg and the Team is following.
 <rbray>	That is something the PSC would presumably discuss.
 <FrankW>	I am not sure how many branches will be active, but I think it would be fine to have local/special branches in which experiments can be pursued before issuing an rfc to merge it into trunk.
 <rbray>	mloskot: Yes and no. The 3.2 stream is mainly in bug fix now.
 <mloskot>	rbray: I understand.
 <gboone>	What would creating an RFC for previous 3.2 submissions achieve?
 <rbray>	FrankW: yes that makes sense. Generally there will be two active, trunk and a release prep.
 <mloskot>	As an example, I see RFC could be created for stuff like "[fdo-dev] New API function on FdoIConnection" announcements.
 <FrankW>	gboone: Documenting them, giving us a chance to refine how they operate, giving us some experience with rfcs.
 <FrankW>	But I don't think we need rfcs for stuff already in trunk.
 <rbray>	Yes I agree. Maybe the release notes could cover the changes in 3.2.
 <mloskot>	I don't think too.
 <rbray>	RFCs for all changes going forward.
 <gboone>	We have been keeping the trunk and 3.2 branch in sync
 <mloskot>	rbray: +1
 <FrankW>	had no idea trunk was distinct from 3.2.
 <rbray>	FrankW: I don't think they are different at the moment.
 <FrankW>	Ah ok, cool.
 <rbray>	FDO 3.2. has been branched for an upcoming MG release. MapGuide 1.1 sometime in December (hopefully).
 <gboone>	I believe that some fixes in th trunk have not been moved to the 3.2 branch
 <gboone>	I have seen several GDAl submissions. However, this sync is not auomatically required
 <gboone>	It depends on the requirements of the branch
 <gboone>	Typically, the 3.2 chnges re automatically moved to the trunk
 <rbray>	Process question: currently we branch near a release. Is that the way GDAL/OGR adn MapServer work?
 <FrankW>	rbray: Generally MapServer branches when the release is issued.
 <FrankW>	GDAL has been haphazard but plans to follow the mapserver model.
 <FrankW>	So mapserver does suffer a "quiet time" when new development is set aside in favor of stabilization.
 <FrankW>	But we avoid having to put bug fixes in too many places.
 <rbray>	Is that because of limitations in CVS branch/merge?
 <FrankW>	(I should say, I hope GDAL will follow the mapserver model depending on feedback from the GDAL PSC)
 <mloskot>	I can say how GEOS works. It uses tags and after trunk is stable and is released, it's tagged.
<mloskot>	In GEOS branches will be used to fork for new/deep changes/features and merged back to trunk, and next stabilized and tagged.
 <FrankW>	rbray: I frankly don't know how to do 'merges'. I hear it is somehow easier in svn but I just find it all conceptually challenging.
 <rbray>	SVN generally has much better support for branch/merge. But internally we have all discussed the pains of submitting fixes in two places.
 <mloskot>	FrankW: don't worry, I merge FDO branches each week and it works very well ;-)
 <gboone>	It is somewhat painful, but the svn merge command is easy to use
 <gboone>	Building and testing is the painful part
 <hobu>	rbray: my opinion is that some if it may have been cvs branch/merge issues. I think a major reason is so that feature churn has to stop for a while and let things settle down.
 <mloskot>	hobu: in trunk.
 <FrankW>	Well, I still think holding off branches till at late as is practical is a good practice.
 <rbray>	hobu: Thanks that makes sense.
 <mloskot>	freezing 'trunk' shortly before releasing and applying only bug fixes but no new features makes it easier because there is one branch developers work with, no merging.
 <rbray>	FrankW: Agreed, but holding off till release may not always be practical. We may be working on featrues for next release will fixing bugs on the one about to be released.
 <mloskot>	After freezed trunk is stable (bugs are fixed), then it moves (copy) to tag
 <mloskot>	This is the most common model I've observed with SVN.
 <hobu>	figuring out who to blame during the freeze is also easier with MapServer's release scenario :)
 <FrankW>	rbray: agreed, I'm just suggesting as late as is practical.
 <mloskot>	rbray: That makes sense.
 <rbray>	Yes and I think that makes sense. I know a few folks that will be happy about that.
 <FrankW>	With trunk/release branching timing presumably worked out by the PSC.
 <rbray>	FrankW: Yes that is a PSC role.
 <gboone>	I also am concerned about banching too late in the release process for clients such as Map
 <rbray>	So I'll add authoring of development process to the task list on the Wiki. This branch discussion should be captured there.
 <mloskot>	rbray: so the branching strategy discussion is still open?
 <gboone>	Closing the Trunk for extended periods is non appealing
 <rbray>	gboone: Yes that is where it gets sticky. We'll have to see how it goes over time.
 <rbray>	mloskot: Yes. I think we need a development process document that captures things like branch strategy.
 <mloskot>	I imagine, ideally, fdo process is planned and realized first, then fdo-dependant producs.
 <mloskot>	rbray: good
 <rbray>	However I think we are all pretty much saying the same thing. Timing of branches is really important.
 <gboone>	Yes
 <mloskot>	yes
 <mloskot>	I'd like to ask back about RFC.
 <rbray>	mloskot: Go ahead.
 <mloskot>	one sec
 <mloskot>	Some time ago I got document for Brent Robinson.
 <mloskot>	It was FDO Schema Manager Design where new API was introduced and explained.
 <rbray>	yep
 <mloskot>	Are you, the main FDO development team, going to move with this docs to RFC-based discussion?
 <rbray>	Going forward that would be an RFC.
 <rbray>	Any and all changes need to be handled and documented via RFC.
 <rbray>	That applies to internal and external development.
 <rbray>	Otherwise it's not open is it?
 <mloskot>	That perfectly answers my question.
 <rbray>	The MG PSC is currently discussing a template / process for RFCs. It is an interesting discussion. I will forward to the FDO  PSC mailing list for those not on both.
 <mloskot>	rbray: right,it wouldn't be open.
 <rbray>	Let's table RFCs for the next meeting agenda. We can go over a template an process for them.
 <mloskot>	Good idea, I have some more questions about RFC.
 <gboone>	Our process also needs to explain the role of and FDO 'Contributor' and how a contributor can submit a code submission for review, obtain sisn-off and drop the code
 <mloskot>	+1
 <FrankW>	would be pleased to let RFC templates settle out in MG PSC and we can work from what they come up with.
 <rbray>	Before we run out of time, how often should we meet on IRC. My thoughts are that we should meet weekly until the PSC is up and running. Maybe another 4 weeks or so.
 <rbray>	Then drop back to as needed and handle most stuff by e-mail.
 <FrankW>	rbray: +1
 <mloskot>	gboone: I would suggest to explain all current and future policies in RFC, even if they are already set.
 <gboone>	+1
 <mloskot>	+1
 <orest>	+1
 <rbray>	What about dev meetings? <mloskot> I know you for one have asked for these.
 <mloskot>	rbray: I asked because I was asked :-)
 <mloskot>	The idea of such meeting(s) came from Gary Lang on FOSS4G
 <rbray>	FrankW: Does MapServer have regular dev meetings on IRC?
 <mloskot>	As I understand it could be a good idea to make up the development team working closer, etc.
 <FrankW>	MapServer does not have regular developer meetings.
 <gboone>	I think it could be useful. However, using IRC to facilitate these meetings is somewhat limiting......
 <FrankW>	Though some developers are often in irc.
 <hobu>	rbray: we started having ~weekly meetings during release freeze though
 <mloskot>	gboone: First idea I've heared from Gary was about face-to-face, but this may be difficult.
 <mloskot>	So, I think IRC, or tele meetings should be easiest.
 <rbray>	Tele meetings are not really that open. With IRC anyone can join, but we are stuck with the keyboard.
 <mloskot>	Right.
 <orest>	I'm just getting used to irc and not sure how smooth develpment discussions can happen in this environment.
 <mloskot>	Generally, the idea of dev meetings was not very formed in details, it was a kind of question "Would it be good/useful/cool?"
 <gboone>	Agree
 <mloskot>	So, this subject is very open.
 <rbray>	Yea that is really the core question at the moment. Would it be useful?
 <FrankW>	I'd suggest we play it by ear for now.
 <rbray>	I agree. Besides we are out of time for this week.
 <gboone>	+1
 <FrankW>	Though I'm hopeful we can have an FDO BOF face to face at the annual conferences.
 <mloskot>	+1
 <FrankW>	Wow, meetings with a strict end time. Interesting concept.
 <rbray>	I will make the suggested updates to the PSC doc and put it up for vote via e-mail.
 <rbray>	FrankW: Wanna see my calendar?
 <FrankW>	rbray: no thanks. :-)
 <mloskot>	lol
 <rbray>	I'll also table the rest of the topics for next week.
 <rbray>	I think it was a really good first meeting BTW.
 <mloskot>	yup
 <gboone>	Yes.
 <orest>	Agreed.
 <rbray>	Ok, so I'll send the minutes later today, start a task list, and create an agenda for next week.
 <mloskot>	Cool, thanks Bob!
 <rbray>	Thanks everyone.