Re: [opendkim:bugs] #222 Enhance config file element handling for unrecognized tags/parameters

From: Scott Kitterman <ietf-dkim_at_kitterman.com>
Date: Mon, 04 May 2015 18:14:48 -0400

On Monday, May 04, 2015 01:25:10 PM Murray S. Kucherawy wrote:
> On Mon, 4 May 2015, Scott Kitterman wrote:
> > In general, I think deprecate (with warnings) and then remove is a good
> > strategy.
>
> I assume "remove" here means "render invalid". For how long should
> something be deprecated before being removed?
>
> My contention is that this just moves back the date when something is
> rendered invalid, once again forcing operator attention. The same
> "surprise" happens, but only after it's possible some undesirable thing
> has been taking place for a while.

At least there was a warning in the meantime. Personally, it'd be nice to see
such warning on stdout and not just in the logs. In the minimal chroots I do
package testing in, normal logging isn't usually set up.

It'd hard to know for sure, but I'd suggest deprecate for one feature release
with warning to logs and stdout and then remove the next.

Scott K
Received on Tue May 05 2015 - 03:03:15 PST