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

[Ross Boylan]

reopen 270018 =
reopen 270019 =
thanks

On Sat, Oct 02, 2004 at 07:58:25PM +0200, maks attems wrote:
> On Sat, 02 Oct 2004, Ross Boylan wrote:
> 
> > I object to the closing of these bugs on all of the following grounds:
> > 
> > 1. They are wishlist items, and the wish has not been resolved, simply
> > dismissed.
> > 2. They are closed on the grounds that the messages are startup
> > messages.  Some are, but some are not.
> > 3. The suggestion that startup messages should not be filtered out
> > seems unwarranted.
> > 4. I responded to earlier requests for exact log lines, but the bugs
> > are now being closed because I have not provided filter patterns.
> > This is essentially a policy that a bug should be closed unless the
> > user provides the fix.  That is unreasonable.
> > 5. The bugs were closed less than one week (and no weekends) after a
> > note threatening to close them.  That is insufficient time for a
> > response.
> > 
> > 
> > In reviewing the logs, I see that my message with the exact log lines
> > for the serial/ppp drivers did not get through; I can send that.  It
> > will take me a little while to do so.
> > 
> > In short, I think the bugs should remain open.  As they are wishlist
> > items, there is no great urgency in dealing with them, but dismissing
> > them is inappropriate.  The grounds given for closing the bug are
> > either incorrect or inappropriate.
> 
> neat,
> both bugs were tagged moreinfo, 

If you're going to be this aggressive, you should get your facts
right, and you haven't.  At the simplest level, the BTS only shows
270019 tagged more info.

Second, I responded to requests for more info on both bugs.  For
270019 I unfortunately sent the info to a developer (I assume a
maintainer), but neglected to cc the bug report.  I have just
corrected that.

> on several request no valid info were provided.

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"?

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

For both bugs *some* log lines are available.  The "valid" is perhaps a
reference to the log lines being start up messages in some cases
(270018).  More on that just below.

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

So, if there is such a policy, I suggest reconsidering it.  logcheck
will be most useful if it removes all routine messages.  If necessary,
the startup messages could be filtered out only at the more relaxed
(e.g., workstation) levels.

> exceptions are common stuff for desktop users.
> 
> the current logcheck maintainers care not having invalid bug reports
> lying around, so either reopen the bug with requested info
> or any time later open new bug again with correct information
> to be handled with.

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.

I understand that writing rules for a bunch of packages that are not
logcheck's, and not necessarily familiar to the logcheck developers,
is a large and difficult job.  In fact, it seems to me that might
plausibly be the responsibility of the maintainer of the other
packages.   Apparently that is not the division of labor (though I
think some packages do supply their own logcheck files).  Since the
logcheck maintainers know logcheck, and the maintainers of the other
packages know their logging behavior. some collaboration would be
best.

Although, in time, I can provide all the log messages I see, I am not
likely to see all the log messages.  As I noted for 270018, I haven't
sent a fax in awhile, so have none of the associated lines to send.  I
almost never receive faxes, so won't have those messages.  I don't run
a modem pool, or a variety of hylafax services, so I won't get those
messages.  So some help, in this case from the hylafax maintainer,
would probably be, uh, helpful.