What is the future of logwatch?

[Yaakov Nemoy]

2010/3/17 Karel Klic <kklic at redhat.com>:
> Hi Yaakov,
>
> please see below.
>
> On 03/16/2010 10:31 PM, Yaakov Nemoy wrote:
>> Hey List,
>>
>> In the org that i work for, we use logwatch for log monitoring. Since
>> puppet is too new to have a module in logwatch, i've had the 'joy'
>> recently of attempting to write a functional module. In doing so, i
>> have a number of issues i would like to bring up about logwatch in
>> Fedora (and RHEL/CentOS).
>>
>> To begin with, like a good netizen, i sent a message to the mailing
>> list upstream. So far i've heard no reply. There's the chance that it
>> got caught in my spam filter, but i've gotten one message from the ML
>> already. It feels like upstream is dead. There has also been no
>> release since 2007. Since it still 'just works' i won't bring out the
>> fire and brimstone and demand it be removed, but i would like to know,
>> how are we going to support this?
> Yes, the upstream is almost dead. Nevertheless I believe if someone
> (anyone) starts to be active on their mailing list, it will make things
> move again in a good direction. If it does not, it makes sense to do a
> fork, because a _lot_ of people use the package, send patches, and
> improve logwatch in a long run.

I would like to think so, but it takes more than just a single email
asking them to accept something upstream. Let alone the issues i had
getting it to work, and it still isn't perfect. If the community does
perk up, this would be great, but i'm not going to base any decision
myself on that assumption.

> I have had this in my todo list since 5 months or so, even promising it
> to a colleague of mine that time. Unfortunately there are still things
> with higher priority to be done. If you can help and devote some time to
> logwatch, then we should cooperate.

I don't have the time at all myself. I'd rather work with a solution
that works today for our needs.

>
>> This question is important in the context of the issues i had
>> programming for logwatch. A well programmed tool maintains orthogonal
>> features in an orthogonal way. I ran into some serious bugs while
>> trying to develop a robust module. Logwatch has two modes, one for a
>> machine with a single set of logs, and one for generating reports for
>> a machine with multiple logs, namely your centralised logging box. The
>> snippets of code that filter the logs you want to analyse allow you to
>> control for the date range and the machine the logged event was
>> generated on. When trying to code for the puppet logs, my code
>> ultimately only worked on the single nodes, but crapped out on our
>> logging box. After debugging the issue, it's obvious that it's doing
>> some prefiltering per host that is occluding all the puppet logs, when
>> the 'splithosts' feature is enabled. Extending and maintaining this
>> package is going to be difficult without a willing maintainer. If this
>> is just something that needs a bug report, i would appreciate if the
>> package maintainer, according to zodbot Karel Klíč, could speak up on
>> this.
> Extending and maintaining a package are two different things.
>
> I believe that discussing some programming issues and source code design
> is out of scope for Fedora maintainer role. It would be too much work to
> do it for every package.

As long as it currently works, it has every right to be in fedora.
Still, i see it as part of our mission to help shape how people use
open source, so concentrating on the big picture is definitely in
scope. If this means discussing potential programming issues users may
have, and the relevance it has to the distro and our big picture
focus, then it's also within scope. Since programming for it is
fundamentally challenging, i think people are going to move to other
solutions or already have, and that's relevant to discuss. This is
namely my question.

-Yaakov