[Logcheck-devel] logcheck needs help

[Frédéric Brière]

martin f krafft <madduck at debian.org> wrote:
> I don't see myself able to maintain logcheck alone anymore. If
> nobody helps out, I will orphan it and ask for its removal.

Maybe it's time to raise, as you once did yourself, the proposal of
moving rules back into their respective packages.

I did read the previous discussions on this subject, and was not
particularly impressed.  Aside from the loghost issue, the main argument
for logcheck-database seems to be that most DDs are too dumb to write
good rulesets.  That's quite depressing, when you think about it.

Yes, there are some crappy rulesets out there (*cough* fetchmail
*cough*), just as there are (or were) broken parts in other packages
throughout Debian.  The usual response to a situation like this is to
write some documentation (maybe as part of the DevRef?), to better
educate maintainers, and lintian tests, to beat them over the head when
they slip up.


To me, the current situation is like if almost all manpages were written
by a small group of English majors.  Yes, many DDs suck at writing and
maintaining documentation, but they are nonetheless better suited for
the task, since they actually know what they are writing about, and are
the first person aware of any change upstream.  And it they can't deal
with groff, they can always ask for help.

But you, you're in a somewhat losing situation, since you can't possibly
keep up with that's going on upstream, so you're stuck to waiting for
users to get bitten and submit bug reports.  And even then, you're
pretty much limited to writing down a regex that matches that exact
message, with limited knowledge on what particular circumstances would
produce that message, and what other variations there could be.

(I for one have dived into upstream code for a few patches I've
submitted, to make sure I knew what I was doing.  That's not practical
at all on a larger scale, though.)


So, what would you think about testing the waters by contacting a small
sample of maintainers, and tentatively passing the baton for a few
packages at first?


If you're interested in this idea, I would propose a few things that
might need doing/discussing beforehand:

* Given the recent emptying of violations.d/logcheck, do we agree that
  violation-level messages will henceforth be triggered and handled by
  individual packages only?  (IOW, maintainters don't have to worry
  about filtering violations from other packages, including logcheck.)

* Shouldn't we do some cleanup on rules before passing them on?  There
  are many discrepancies in there (ie. [[:digit:]] vs. [0-9]), and I'd
  bet that 90% of address patterns won't match IPv6.  Trying to fix
  those after they have been scattered will likely be painful.

* This might be a good opportunity to raise (once again) the idea of
  macros/templates.  This would not only make the aforementioned cleanup
  much easier, but future maintenance as well.  (I'm assuming that
  exansion would occur at run-time.  Or at least at logcheck
  install-time.  Or else, be handled by dh_something.  But I digress.)

* There should ideally be a central reference point for maintainers,
  with documentation on both syntax (how to write good rules) and
  semantics (where to put them), as well as how to manage the transfer
  from logcheck to their package, where to ask for help, etc.


-- 
You will not censor me through bug terrorism.
		-- James Troup