At 10:48 PM 15/02/2000 -0600, Karl Fogel wrote:
>The reason a good patch gets ignored is that the developers do not
>have time to review the patch with sufficient care. And failure to
>review patches has led to problems in the past (mea culpa), so this is
>not an imaginary problem -- it is quite possible to do harm by letting
>a bad patch in, and distinguishing good from bad is a highly
>non-trivial exercise.
However, if the patches were checked in on a development branch, they could
be made available and tested without impacting on anyone who wanted to work
only with a stable version. I find it ironic that the development of a
source code management tool has such a limited development environment
itself. No lines of development. If the concurrency of the cyclic server
has been used in the last couple of years, I'd be surprised. Might as well
store CVS source code in an RCS or SCCS system.
Furthermore, as we discussed ad nauseum on the CCP list, an improvement to
the situation would be realized by opening up check-in rights to all who
request it, _particularly_ if they restricted themselves to the development
branch.
My reasoning for opening up development wasn't generally agreed to, but I
thought the conclusions were. Does anyone know why development hasn't
opened up yet?
>> Somehow I feel this to be somewhat of a sadistic thing to do to
>> users as well as misusing the whole concept of open source.
>
>Do I have to respond to this? :)
I understand the frustration that caused him to say it. Design goals are a
wonderful thing, but if they become rigid they become a boat anchor that
weighs the user down. We have an award-winning building here that the
architect designed to resemble a First Nations LongHouse, only on a much
grander scale. One of the key design goals was for the plan to be open, as
a longhouse is. Although there are internal walls to this building, none
reach to the ceiling. Sound travels readily throughout.
The people in the building have a hell of a time. Any sound reverberates
throughout the building. Native groups get together in one room to drum,
and suddenly nobody in the entire place can speak to one another, let alone
get any work done.
So they called in the architect to ask him to fix the problem, and ... he
refused. It went contrary to the design goals of an open space, you see.
The fact that the usefulness of the building was greatly reduced was not
the issue for him. His design goals were rigid and the users suffered for it.
Let's try to remember that one of the prime goals of any program should be
that it is useful to the user, and as easy to use as is practical. It is
differences of opinion about where the dividing line between practical and
impractical should be drawn that causes all these arguments.
