Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 90209 invoked by uid 500); 16 Mar 2001 04:32:59 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 90135 invoked from network); 16 Mar 2001 04:32:58 -0000 Message-ID: <001501c0add3$0ad28f50$01000100@SASHIMI> From: "Bill Stoddard" To: Subject: SGI Patch - 10xpatch-2_0a6-6 Date: Thu, 15 Mar 2001 23:39:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N FYI... Mike if you are still reading... This patch had an interesting optimization to avoid using sscanf to determine the HTTP protocol numbers which I just committed to Apache 2.0. This patch also had a lot of extra 'cruft'. The cruft (stm.html, et. al.) made reviewing this patch difficult. Had you submitted the sscanf piece as a seperate patch, it would have been committed within a few days. As it was, there was too much for most of us to review in one sitting and there were multiple changes that were completely unrelated to each other. Should you decide to submit patches in the future (and i hope you do), I suggest you keep the entire patch 'on topic' and scoped to accomplish a very specific purpose. The smaller the patch, the more likely someone will be able to grok it in one sitting and make a decision on it. If the reviewer has to tease out good changes from cruft, they'll just not bother in most cases. I happen to be a bit of a performance junkie myself which is why I am spending my time on this. Bill