On Fri, Jan 03, 2003 at 05:07:09PM -0800, rbb@rkbloom.net wrote:
> On 3 Jan 2003, Karl Fogel wrote:
> > Justin Erenkrantz <jerenkrantz@apache.org> writes:
> > > If I thought we'd realistically have LOCK support in a month, I
> > > wouldn't have proposed this. But, I don't see that happening. So,
> > > I'd hope that people who are saying -0.95 are volunteering for writing
> > > LOCK right now. You don't get to veto something without proposing to
> > > help devise an alternative. =)
Not entirely true...
> > I don't know where that rule came from, but I've certainly never heard
> > of it before. What's being vetoed, or anyway strongly objected to, is
> > the proposal that we deliberately misimplement a part of the DAV
> > standard.
> >
> > And the alternative proposal is: don't do that :-).
>
> That rule kind of comes from the Apache developers. It is usually
> considered rude to veto something and not offer to help fix the problem or
> at least offer a alternative solution to the problem.
It's rude to veto without an explanation of why the code is a problem.
(well, strictly speaking, the veto probably wouldn't even be valid in that
case) Just because somebody offers up broken code doesn't mean that other
people have to come up with the Right solution. If the code is broken, then
it is broken. Simple as that.
I knew one of your original designs for filtering in httpd was broken, but I
couldn't articulate the fix well. I just knew it could consume unbounded
memory, so it was wrong. Eventually, I think it was Tony, pointed out the
"network pushback" as a mechanism for constraining memory use. From that key
point, we developed the output filtering as a group, and it can now operate
in a bounded space, using the network as a throttle mechanism.
The point is: a veto is about broken code, rather than an offer to help.
Usually, it is a +1 which means "great idea, and I'd be happy to help." The
person veto'ing, though, is required by the rules and social custom to
explain why they've imposed that.
> However, that is
> usually because a veto is for code not a concept. If you are veto'ing
> code that implements a specific feature, you should have a good reason for
> the veto, which means that you are also likely to have another option for
> how to implement the same feature.
Yup. We have some ideas on paper, but that doesn't translate into John Doe
being able to commit broken code "unless we spend the time to write the good
code." IOW, broken code can't be used as a means of extorting time from
others to produce the right code.
> If your solution resolves your veto
> (it obviously does) and it solves the original problem, then cool. But,
> this isn't code that is being veto'ed, it is the idea that it is ever a
> good thing to willfully violate a published spec.
Well, you could say that we can't "veto a concept." Fair enough. But
somebody is going to be *real* pissed when they produce code and we veto
*that* :-) Consider it a prediction of a veto :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jan 4 02:39:47 2003