httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <>
Subject Re: svn commit: r230592 - in /httpd/httpd/branches/2.0.x: CHANGES STATUS modules/proxy/proxy_http.c
Date Mon, 08 Aug 2005 23:58:20 GMT
Bill, if you spent more time making your changes understandable
by documenting what they change instead of various random things
totally unrelated to each patch, then maybe people like me could
review them.  Also, it would help a great deal if you would make
a complete set of changes locally, compile and test them locally,
and then present them as a set of logical change sets that achieve
a specific purpose.  Right now I am not even bothering to review
your commits because they are obviously untested and consist of
patch-upon-patch-upon-patch fixing what can only be described as
sloppy programming.

For the 2.0 branch, the changes should fix a very specific bug.
There shouldn't be any style changes or variable renaming.
I don't care if it makes it easier to compare with trunk -- I
only want to compare it to 2.0.x-1.  If it helps, generate the
patch against the last 2.0.x release tag instead of the branch.
If necessary, we should back out all the 2.0.x changes and release
a 2.0.x without them.  I do not consider HTTP request smuggling
to be a blocking issue that requires a redesign of the entire
request reading process.  If I did, the answer would be to EOL
the 2.0 branch and move all development off of it.

For the 2.1+ branches, it is imperative that commits be complete
change sets that have been tested on your local machine to solve
the problem you are trying to fix.  Some people do that by adding
to the test suite during the process of every change.  When I see
more than three commits per change set, I know that the commits
did not work and somebody is just wasting the group's time by
making everyone review unfinished changes.  I can understand that
in the heat of the moment every once in a long while, but you are
doing it every single time you work on something in httpd.  Just
slow down and make sure the changes are comprehensible before
they are committed and others won't be in such a bad mood when
it comes time to vote on them.


View raw message