From docs-return-10112-apmail-httpd-docs-archive=httpd.apache.org@httpd.apache.org Mon Nov 28 16:30:04 2011 Return-Path: X-Original-To: apmail-httpd-docs-archive@www.apache.org Delivered-To: apmail-httpd-docs-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4BAE9975F for ; Mon, 28 Nov 2011 16:30:04 +0000 (UTC) Received: (qmail 63093 invoked by uid 500); 28 Nov 2011 16:30:04 -0000 Delivered-To: apmail-httpd-docs-archive@httpd.apache.org Received: (qmail 63034 invoked by uid 500); 28 Nov 2011 16:30:04 -0000 Mailing-List: contact docs-help@httpd.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: docs@httpd.apache.org List-Id: Delivered-To: mailing list docs@httpd.apache.org Received: (qmail 63026 invoked by uid 99); 28 Nov 2011 16:30:04 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2011 16:30:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.161.173] (HELO mail-gx0-f173.google.com) (209.85.161.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 28 Nov 2011 16:29:57 +0000 Received: by ggnb1 with SMTP id b1so7149002ggn.18 for ; Mon, 28 Nov 2011 08:29:36 -0800 (PST) Received: by 10.50.196.137 with SMTP id im9mr9697032igc.32.1322497776029; Mon, 28 Nov 2011 08:29:36 -0800 (PST) Received: from [192.168.200.193] (74-131-224-250.dhcp.insightbb.com. [74.131.224.250]) by mx.google.com with ESMTPS id j1sm83663174igq.2.2011.11.28.08.29.31 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 28 Nov 2011 08:29:34 -0800 (PST) From: Rich Bowen Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_A9071E4C-3FB7-4367-8A38-B3389D7A2D92" Subject: Re: Error codes Date: Mon, 28 Nov 2011 11:29:30 -0500 In-Reply-To: <201111281721.43694.sf@sfritsch.de> To: docs@httpd.apache.org References: <201111281721.43694.sf@sfritsch.de> Message-Id: <0950B188-54F2-4D46-9206-84F3B4115A2A@rcbowen.com> X-Mailer: Apple Mail (2.1251.1) --Apple-Mail=_A9071E4C-3FB7-4367-8A38-B3389D7A2D92 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 28, 2011, at 11:21 AM, Stefan Fritsch wrote: > On Monday 28 November 2011, Rich Bowen wrote: >> 1) Create file in svn that lists sequential error codes so that we >> know what the next number is. The file should list error code and >> the file in which it is used. Should probably also list line >> number, although that changes over time, so it's approximate. >=20 > The file names and line numbers can easily be extracted by a script (I=20= > am volunteering to write it), no need to track these manually. Excellent. Time saving is always a good thing. :) >=20 >> 2) Find all calls to *_log_?error (Stefan says there's 2700+ such >> calls!) and add the next error code to the beginning of the >> message. In parens, perhaps?. Update the file in #1. >=20 > I would prefer "AH1234: Don't panic". It's one character shorter than=20= > "(AH1234) Don't panic" and horizontal screen space is always short=20 > when viewing the error log. Sounds good to me. >=20 > A question on procedure: Do you want to add all error codes at once=20 > and then fill in the descriptions or add the error codes as the=20 > documentation evolves? If the former, some scripting would probably=20 > save a lot of work, too. If it can be done all at once with a script, that would be great. The = only concern from there would be the ease of applying that change to = earlier versions. Presumably the trunk -> 2.4 patch would work pretty = well, but -> 2.2 would take a lot of work. Not sure that it would be = worth it, though. I'm in favor of making this a 2.4-only effort. >=20 > I am not sure that every debug message needs a code, maybe one could=20= > at first only tag those of level info or higher? Or maybe even=20 > warning? Ah. Good point. Yes, we should probably skip stuff in Debug, unless it = makes sense to add them on a case-by-case basis later on. (Not sure what = would justify that, but perhaps some messages are more common than = others? More important? More =85 something.) I would say warn and = higher, but perhaps it merits further discussion. Adding them to info = now might save hassle later on if we wanted to further document those, = and costs us nothing now, except for 6 characters in the log message. = What do folks think? -- Rich Bowen rbowen@rcbowen.com :: @rbowen rbowen@apache.org --Apple-Mail=_A9071E4C-3FB7-4367-8A38-B3389D7A2D92 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Monday 28 = November 2011, Rich Bowen wrote:
1) Create = file in svn that lists sequential error codes so that = we
know what the next number = is. The file should list error code and
the file in which it is used. Should probably also list = line
number, although that = changes over time, so it's approximate.

The file = names and line numbers can easily be extracted by a script (I 
am volunteering to = write it), no need to track these = manually.

Excellent. Time saving = is always a good thing. :)

2) Find all calls to *_log_?error = (Stefan says there's 2700+ such
calls!) and add the next error code to the beginning of = the
message. In parens, = perhaps?. Update the file in #1.

I would prefer = "AH1234: Don't panic". It's one character shorter than 
"(AH1234) Don't panic" = and horizontal screen space is always short 
when viewing the error = log.

Sounds good to = me.


A = question on procedure: Do you want to add all error codes at once 
and then fill in the = descriptions or add the error codes as the 
documentation evolves? = If the former, some scripting would probably 
save a lot of work, = too.

If it can be done all at = once with a script, that would be great. The only concern from there = would be the ease of applying that change to earlier versions. = Presumably the trunk -> 2.4 patch would work pretty well, but -> = 2.2 would take a lot of work. Not sure that it would be worth it, = though. I'm in favor of making this a 2.4-only = effort.


I am not = sure that every debug message needs a code, maybe one could 
at first only tag those = of level info or higher? Or maybe even 
warning?

Ah. Good point. Yes, we should probably skip stuff = in Debug, unless it makes sense to add them on a case-by-case basis = later on. (Not sure what would justify that, but perhaps some messages = are more common than others? More important? More =85 something.) I = would say warn and higher, but perhaps it merits further discussion. = Adding them to info now might save hassle later on if we wanted to = further document those, and costs us nothing now, except for 6 = characters in the log message. What do folks = think?


--
Rich Bowen
rbowen@rcbowen.com :: = @rbowen
rbowen@apache.org





= --Apple-Mail=_A9071E4C-3FB7-4367-8A38-B3389D7A2D92--