Arved, See comments below.
Arved Sandstrom wrote: >1. I can see a place for structured (that is, planned) communication: >conference calls, scheduled meetings on a system like Peter describes, use >of something like MSN Messenger, setting up an IRC channel and everyone >getting together there. But I don't think that's the problem at the moment. > > The problem is going to be with the timing. Scheduling a regulat chat would be a good idea because folks can try to schedule around that and, who knows, it could get to be a habit. >2. Can we do better with CVS? ,,, If we used watches, we could >set things up so Karen might get notifications on 'cvs edit' for >such-and-such a package, Peter might get 'cvs edit' notifications on another >package that he selects, and so forth, whatever is of interest. > >This would at least give us notifications at the other end of the process, >which is when a developer (say, Keiron) _starts_ to work on a file. > >This is a bandaid, though. I am just as bad as Karen when it comes to >wanting to have everything just-so before I check something in. This is OK >with reserved checkout systems like SourceSafe default, but it's lousy for >the unreserved checkout CVS case. > > Yes and no. I think that the motivation for the CVS model was dissatisfaction with the RCS/SCCS lock model in precisely these situations; multiple developers, with some in the process of lengthy modifcations. I'm with you and Karen on this. My flesh creeps at the idea of committing code which I know to be in a shambolic state. It's worse if I have to then merge in someone else's changes, then iterate over the whole process a couple of days later. The situation is worse at the moment because basic design issues are being worked out on the fly, so there are going to be large, incompatible areas of the code between Karen and Keiron until the design is settled. My design is even more incompatible, so when I check my code in, I will be setting up my own branch. It seems to me that Karen might productively branch her changes, and track what Keiron is doing by merging in from his code. Take the current issue with her subclassing of Keiron's code. She need not have the code commented out in her branch, and she can explore the issues in safety. When she has proven the concept, she can merge back into the trunk. I don't think she is going to be left behind, but if she cannot develop her ideas in relative isolation from other ongoing and incompatible changes, a lot of her time may be spent in tedious merging activity. >I would nevertheless suggest maybe trying the watch features. > Agreed >What we lack is ownership. We've got a whack of committers and a fair-few >active ones, and maybe it's now time to allocate ownership of stuff on both >branches. Ownership does _not_ mean you are the only person working in that >package or packages - what it means is you are the POC for work being done >in that package. You are the arbiter of disputes. We could even combine this >with BugZilla ownership, possibly. > > The only trouble I see with this is that the only ones who are really familiar with the code are also *very* busy with development, part-time. Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
