FDO PSC Meeting 10-30-2006
Revision as of 01:08, 11 May 2011 by Wiki-PhoenixAllen (talk | contribs)
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.