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

[Ross Boylan]

This is wandering a bit far afield from the original bug, but lacking
a better forum, I'll continue here.
On Sun, Oct 03, 2004 at 03:10:28PM +0100, Jamie L. Penman-Smithson wrote:
> 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.

I agree it's not too difficult, though I have found it is not entirely
trivial either (plenty of my regex's have had bugs on the first cut).
In my original submissions for both bugs in question I had some
regex's, though I noted at the time they were not adequate.  (They
were only intended as clues and aids).  There are also some nuances,
such as the correct general regex for a serial port, or even for a
system name, that I'm not sure I would get right.  As I noted earlier,
ttyS[[:digit:]] (maybe followed by {1,2}) works for me, but I have a
feeling there are a lot of other names the serial ports are known by.

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

I am sorry that you should have this impression.  It is not accurate,
and I don't think it's based on a reasonable reading of what I wrote.
For example, I said " If you lack the time, information, or
inclination to add the features, you can just leave [the bug/feature
request] them there."

The issue is not whether maintainers should create regexes when I snap
my fingers, but whether I or any bug submitter should be required to
produce them when you snap yours, under penalty of having the request
closed for non-compliance.  This implies holding bug submitters to a
standard that you find offensive even for maintainers.  It also
implies that "a bug is not a bug unless you provide a fix," which is
extremely inappropriate.

Though no one has raised the issue, I am in fact ready to try out, and
even to try to generate, regex rules (that is, more production-ready
versions than my current ones).  Ordinarily I'd be happy to do that.
I'm not willing to do it for requests tagged wontfix (both 20018 and
19, currently).  I'm also not happy to do it when someone holds a gun
to my head and says "you must do this or I close the bug."

The latter statement is, in fact, profoundly disrepectful to me.  I
consider some of the responses from attems (including the wontfix)
abusive in other respects as well.

This is even more galling since I have put in a fair amount of time
into logcheck, including about a day's work to understand it and
provide a patch documenting the behavior for the man page.  Portions
of that have been incorporated into the released version.  I have also
put several days' work into patches to hylafax, and they have been
incorporated in toto upstream.

I am also disturbed by a seeming continuous creep in what is expected
as the minimum tolerable standards for a feature request.  I provided
a general request and some regex's.  I was told the regex's were no
good (I agree they were not suitable for use as stated) and asked to
provide log messages or more robust regex's.  I provided log
messages.  Now, apparently, I am told that I must provide regex's.

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

It may be that maintenance/aesthetic considerations outweigh the
advantages of filtering out start up messages.  I believe there is a
benefit to removing such messages that should at least be considered.

I do not appreciate being told my request is stupid or invalid because
it includes such messages.  Such a statement, aside from being
unpleasant, assumes that I should be aware of some policy that I have
never known of, and as far as I know I had no way of knowing.  Second,
it converts what could be a reasonable discussion of the merits of
alternatives (such as we kind of just had above) into name calling,
and ruling one position out a priori.

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

Well, this exposes a lingering difference in view points (as does your
remark earlier about not filing the bug until you have the log
messages in hand).  I did not file a feature request with just a
subject line, but in fact, I think that is reasonable behavior.  A
feature request is, after all just a request, and "I'd like logcheck
to handle messages from package xxxx" is, I think, a reasonable
request.

If such a request were made with the expectation that much action
would follow from that alone, it would be naive or optimistic.  If it
were made in the belief that the maintainers had an obligation to
provide the feature, that expectation would be obnoxious (as well as
unrealistic).

In general, it seems to me the most desirable way to produce logcheck
rules would be a collaboration between logcheck maintainers,
maintainers of the other relevant package, and users.  As I noted in
my earlier post, an individual user is unlikely ever to see the full
set of routine messages from a packages.  You complain it is
unreasonable to expect the maintainers to know the messages for a given
package; it is almost as unreasonable to expect an individual user to
be able to provide the full range of messages from a package.  For
270019 the situation is a bit muddy since (I think)
the messages are a mix of kernel messages and those from various
communications packages (chat, ppp).

This process is not advanced by telling someone requesting a feature
that they are a jerk.

Although you have attributed unreasonable positions to me without, I
believe, much basis, I appreciate the relatively civil tone of your
remarks.  I hope that this messages clarifies my views.

Perhaps we could get on with adding these features.