FDO PSC Meeting 10-30-2006

FDO PSC - 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 to:

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

IRC Log

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?
Greg_Boone	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.
Greg_Boone	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?
-->|	RobertF (n=RobertF@12.160.193.229) has joined #fdo
rbray	Yes that is correct. Sure we can make it 48 hours. What does everyone else think?
Greg_Boone	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.
-->|	hobu (n=hobu@epimetheus.hobu.net) has joined #fdo
rbray	So I'll make that change as well. Any other comments on the PSC document?
-->|	FrankW (n=nchatzil@ip-209-172-33-142.reverse.privatedns.com) has joined #fdo
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
<--|	RobertF has left #fdo
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.
Greg_Boone	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.
Greg_Boone	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	Greg_Boone: 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,
Greg_Boone	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.
-->|	danmo (n=dmorisse@QUBCPQ14-1177866169.sdsl.bell.ca) has joined #fdo
Greg_Boone	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.
Greg_Boone	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	Greg_Boone: 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.
Greg_Boone	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).
Greg_Boone	I believe that some fixes in th trunk have not been moved to the 3.2 branch
Greg_Boone	I have seen several GDAl submissions. However, this sync is not auomatically required
Greg_Boone	It depends on the requirements of the branch
Greg_Boone	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.
hobu	listens
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 ;-)
Greg_Boone	It is somewhat painful, but the svn merge command is easy to use
Greg_Boone	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.
Greg_Boone	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?
Greg_Boone	Closing the Trunk for extended periods is non appealing
rbray	Greg_Boone: 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.
Greg_Boone	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.
Greg_Boone	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	Greg_Boone: I would suggest to explain all current and future policies in RFC, even if they are already set.
Greg_Boone	+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.
Greg_Boone	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	Greg_Boone: 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?"
Greg_Boone	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.
Greg_Boone	+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
Greg_Boone	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.