Daniel Russel wrote: >> You can't really expect changes to be committed rapidly if you make them >> before discussing the implications, because that requires everyone to >> agree with everything you do, which is not likely to be the case. ;) > Well, I don't think we have ever had an objection from anyone else :-)

They come and complain to me in person. And it is hard to object to a change which isn't mentioned on the list, until much later when you realize your code doesn't work any more.

> Discussing thing beforehand doesn't help anyway, since it requires that > I stop what I am doing and work on something else while the discussion > occurs rather than just making the changes.

You can have discussion before or discussion afterwards. It's your choice. But just going ahead and writing the code is quite annoying if it conflicts with code other people are writing in the meantime.

> Sure. Much of the problem is the frequency of changes, not the latency > of the commit time (although the unpredictability of the commit time is > sometimes annoying). I am not always complaining about you. Just > sometimes :-)

You can only predict the commit time if you can predict whether I'll agree with your changes. One way to know that is to mention them on the list before you make them.

Ben