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. ....Roy
