[ovs-dev] [PATCH] vlog: deprecate --syslog-target argument

[Ansis Atteka]

Thanks for review, I pushed this.

On Tue, Sep 29, 2015 at 4:49 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Sat, Sep 19, 2015 at 02:14:45PM -0700, Ansis Atteka wrote:
>> On 19 September 2015 at 09:37, Ben Pfaff <blp at nicira.com> wrote:
>>
>> > On Fri, Sep 18, 2015 at 04:09:48PM -0700, Ansis Atteka wrote:
>> > > On 18 September 2015 at 15:35, Ben Pfaff <blp at nicira.com> wrote:
>> > >
>> > > > On Wed, Sep 16, 2015 at 07:29:30PM -0700, Ansis Atteka wrote:
>> > > > > Commit fe089c0d1e18 ("vlog: abstract out interface to syslog daemon")
>> > > > > introduced --syslog-method flag that supersedes --syslog-target flag
>> > by:
>> > > > > 1. making logging format configurable
>> > > > > 2. letting daemon to also talk over UNIX domain socket (this is handy
>> > > > >    when local rsyslog daemon is running in different network
>> > namespace
>> > > > >    on the same host)
>> > > > >
>> > > > > Signed-off-by: Ansis Atteka <aatteka at nicira.com>
>> > > > > ---
>> > > > >  NEWS       |  1 +
>> > > > >  lib/vlog.c | 10 ++++++++++
>> > > > >  2 files changed, 11 insertions(+)
>> > > > >
>> > > > > diff --git a/NEWS b/NEWS
>> > > > > index ca22c8e..8bdaf3e 100644
>> > > > > --- a/NEWS
>> > > > > +++ b/NEWS
>> > > > > @@ -21,6 +21,7 @@ Post-v2.4.0
>> > > > >       targets to run a new system testsuite.  These tests can be run
>> > > > inside
>> > > > >       a Vagrant box.  See INSTALL.md for details
>> > > > >     - Dropped support for GRE64 tunnel.
>> > > > > +   - Mark --syslog-target argument as deprecated.
>> > > >
>> > > > In the past when we've deprecated features we've also given a date
>> > after
>> > > > which we might remove the feature.  It's usually 6 to 12 months out.
>> > Do
>> > > > you want to do that here?
>> > > >
>> > >
>> > > > Acked-by: Ben Pfaff <blp at nicira.com>
>> > > >
>> > > I will mark this as "to be removed in 6 months" and push.
>> >
>> > Can you give a specific date (e.g. "March 2016") so that users don't
>> > have to guess what the start date is?
>> >
>> Instead I put "will be removed in the next release" since my personal
>> opinion is that this feature is really insignificant and can be removed
>> sooner rather than later.
>>
>>
>>
>> > > Do you think that we should have a sentence or two in CONTRIBUTING.md
>> > file
>> > > about "feature deprecation guidelines"? If so I can try to write this up.
>> >
>> > That sounds like a good idea to me.
>> >
>> I sent out proposed changes to CONTRIBUTING.md.
>>
>> I agree that "in 6 months" is not clearly interpretable. However, even with
>> absolute times there could be some confusion if it takes for us very long
>> time to deliver release (just like 2.4.). In this case if current release
>> spans over March 2016 then it would not be clear to users when they should
>> be prepared for the feature to be removed.
>
> It sounds like you've thought this through.  I'm happy with it.