conf/104884: Add support EtherChannel configuration to rc.conf

[Doug Barton]

The following reply was made to PR conf/104884; it has been noted by GNATS.

From: Doug Barton <dougb at FreeBSD.org>
To: Brooks Davis <brooks at FreeBSD.org>
Cc: Florent Thoumie <flz at FreeBSD.org>, 
 Norikatsu Shigemura <nork at FreeBSD.org>,
  freebsd-bugs at FreeBSD.org,  FreeBSD-gnats-submit at FreeBSD.org, 
 freebsd-rc at FreeBSD.org
Subject: Re: conf/104884: Add support EtherChannel configuration to rc.conf
Date: Thu, 08 Feb 2007 16:07:42 -0800

 Brooks Davis wrote:
 > On Thu, Feb 08, 2007 at 11:48:04PM +0000, Florent Thoumie wrote:
 >> Brooks Davis wrote:
 >>> On Thu, Feb 08, 2007 at 11:30:41PM +0000, Florent Thoumie wrote:
 >>>> Brooks Davis wrote:
 >>>>> On Thu, Feb 08, 2007 at 01:55:16PM -0800, Doug Barton wrote:
 >>>>>> Brooks Davis wrote:
 >>>>>>
 >>>>>>> The default should be an empty list which results in nothing happening.
 >>>>>>> I'd suggest making empty list the value for the default gif_interfaces
 >>>>>>> in /etc/defaults/rc.conf in both branches, removing support for NO in
 >>>>>>> CURRENT and emitting a warning in stable.
 >>>>>> How about issuing a warning for NO in both branches? Whether I agree
 >>>>>> with you or not on the importance of keeping things clean and
 >>>>>> consistent, I definitely do not want to err on the side of pedantry
 >>>>>> over usability.
 >>>>> That would be fine.  I don't really care as long as it's deprecated.
 >>>>>
 >>>>> FWIW, only users who don't update /etc/defaults/rc.conf or who manually
 >>>>> set gif_interfaces="NO" would be effected so the size of the set of
 >>>>> effected users is probalby close to epilon and even all that will happen
 >>>>> is cloning an extra interface and then not configuring it so it should
 >>>>> be basicly harmless to just remove direct support for it.
 >>>> Fine with me as well. Should we make it a warning on RELENG_6 and an
 >>>> error on HEAD, or a warning on both. The former being be what I was
 >>>> planning to do, ie. remove support for "NO" in HEAD but issue a message
 >>>> saying semantics have changed. The latter would mean identical code in
 >>>> both HEAD and RELENG_6 (so "NO"-compatibility in both branches), but
 >>>> we'd need a reminder to remove this "NO"-support in HEAD once RELENG_7
 >>>> is branched.
 >>> I'd say a warning in both.
 >> Re-reading Doug's message, he's probably thinking the same thing, but
 >> this is for gif_interfaces only, right?
 > 
 > That's what I'd do.  There's no reason to introduce support for an
 > instantly deprecated feature in a new variable, particularly since
 > gif_interfaces is the odd one out.
 
 Yes.
 
 Doug
 
 -- 
 
     This .signature sanitized for your protection