project goals and standards

MrC wrote:
> I would personally like to see  (in no particular order):
> ...
> 2) per-filter documentation

Yeah, I was wondering why there wasn't any POD in the filters.


> 3) some general project goals
> 4) some push toward report consistency where appropriate
> 5) more shared, documented common routines for use by filters

The previously mentioned wiki idea could go a long way towards achieving 
these. Then we could document the conventions, coding style, and APIs. 
Should one of us just setup a wiki at Wikispaces?

On a related note, has anyone created skeleton script/filter/conf files? 
Having templates distributed with the project might help in making user 
contributed files more consistent.


> 7) common Unmatched entries reporting, to assist users in submitting 
> reports (rather than tolerating Unmatched lines forever).

So like an email address where users could forward reports showing 
unmatched entries? Or something more automated?


> 8) more integrated debug

I see there is a debug environment variable that some of the scripts 
make use of. I haven't had a need to do any debugging yet when running 
the scripts through logwatch. I've been able to adequately test and 
debug filters in isolation. What requirements do you have in mind that 
aren't being met?


> 9) more detailed change logs

That's mostly a release management issue to be dealt with by whoever 
creates the releases, with the exception that a bit of scripting could 
be used to compile change logs from CVS.

By the way, does the project have an issue tracking system somewhere? I 
only recall seeing the mailing list referenced as the place to report 
bugs. An issue tracking system is pretty critical for not only tracking 
bugs, but planning development as well.


> 10) push towards more generalized use (vs once/night: I don't think the 
> goals of 10 years ago are in alignment with today's more hostile and 
> ubiquitous Internet)

I'm planning to set up my installations to run daily and weekly passes 
at two different detail levels. I saw that logcheck runs its scans 
hourly. What specifically did you have in mind?


> I've been contemplating forking a new project if my personal goals are 
> not in alignment with the logwatch project's.

In my experience with open source projects (dating back to the '80's 
before they were called "open source"), there's typically some hostility 
and dismissiveness towards new ideas. So far the project lead, Kirk 
Bauer, hasn't been too vocal, but of the postings I have see, seems open 
to new ideas. So I don't see any need for forking at this point.

  -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/