Bug#270019: [Logcheck-devel] Bug#270018: 270018, 270019 should remain open

[Jamie L. Penman-Smithson]

On Sat, 2004-10-02 at 12:14 -0700, Ross Boylan wrote:
> Your requests came just a few days ago.  Aside from the fact that you
> need to allow a bit longer for a response, the messages said to provide
> "regular messages + rules or i close that bug."  The implication is
> that if I fail to provide the fix ("rules") you will close the bug.
> I'd call that an invalid request.  A bug, or in this case a feature
> request, should not be closed simply because the submitter can't offer
> a fix (or feature implementation).  Perhaps you meant "+" in the sense
> of "or"?

Creating regex rules for log messages is not difficult. Start by taking
a look at the rules already in logcheck.

Start by having some respect for the people that maintain debian
packages. They do not sit around at your whim ready to create regex
rules for packages whenever you click your fingers. 

> While I understand the request for log lines, I think it is
> problematic too, for reasons I give at the bottom of this message.

You can't expect people to magic log messages out of thin air for
packages that they do not use. If you can't provide the log messages to
be filtered, wait until you can - before opening a bug report.

> > startup messages of daemons shouldn't be filtered by logcheck,
> 
> I am not aware of this policy and I do not think it is a good one.
> The purpose of logcheck, as I understand it, is to filter out
> "non-events" from the logs, so that unusual things are immediately
> visible.  Adding "usual" items dilutes this purpose.

Unless you start and stop your processes every 5 minutes, filtering
startup messages adds unnecessary cruft IMO.

> So, if there is such a policy, I suggest reconsidering it.  logcheck
> will be most useful if it removes all routine messages.

No, it'll be bloated with rules that are hardly needed. Unless you'd
like to maintain all of the many, many additional rules needed?

> Look, these are both wishlist bugs for features.  As such, I think
> merely submitting a bug with the subject line would be adequate to
> indicate a desired feature.  I have done much more.   If you lack the
> time, information, or inclination to add the features, you can just
> leave them there.

A subject line is not a proper bug report, contrary to what you may
think.

-j

-- 
-jamie <jamie at silverdream.org> | spamtrap: spam at silverdream.org
 w: http://www.silverdream.org | p: sms at silverdream.org
 pgp key @ http://silverdream.org/~jps/pub.key
 14:30:01 up 8 days, 18:19, 14 users,  load average: 0.28, 0.20, 0.16

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/logcheck-devel/attachments/20041003/8473cc23/attachment-0001.pgp