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.

>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.


To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to