httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: voting
Date Thu, 08 Jan 1998 13:23:56 GMT
Dean Gaudet wrote:
> You know, in those cases where I've complained about aspects of other
> people's patches that bother me.  If we were in a commit-then-review
> situation I would have just fixed what bothered me after you committed.
> This saves time.  Words are not exact, code is exact. 

I think our current behavior shows quite clearly that if we went
this route, committed code would be, by default, always be "approved".

As bad as this current method is, the whole idea was that it
"forced" people to look at the patches and semi-protects us
for stuff "sneaking" in without it getting a look-through.

'Course, it worked a lot better when more people took the time
to review the patches and vote. But I don't think the solution
is to implement exactly what we've been trying to avoid.

It also provides a sense of checks-and-balances. In the above
example, let's say that a section of code "bothered" you and
you went ahead and fixed it to your satisfaction. What if your
fix bothered the original submitter and they didn't like or want
your fix? They'd repatch. At which point this could continue for
awhile until a discussion ensued. So we wouldn't avoid the words
at all, and the result would be a crazy CVS log :-)

Or worse, what if the original submitter didn't like the changes
and didn't know and then did something else that depended on
the way it was originally code?

Me? I'm not that comfortable with the Lazing Voting mode for just
these reasons, but I think it has it's place and it's useful for
that place... 

Dean, all good points. I can understand your frustration... I just
don't have a warm-and-fuzzy with your solution :)
      Jim Jagielski            |       jaguNET Access Services           |
            "Look at me! I'm wearing a cardboard belt!"

View raw message