Rui Paulo wrote:
On 2013/04/12, at 22:31, Scott Long <sco...@samsco.org> wrote:
On Apr 12, 2013, at 7:43 PM, Rui Paulo <rpa...@freebsd.org> wrote:
On 2013/04/11, at 13:18, Gleb Smirnoff <gleb...@freebsd.org> wrote:
Lack of maintainer in a near future would lead to bitrot due to changes
in other areas of network stack, kernel APIs, etc. This already happens,
many changes during 10.0-CURRENT cycle were only compile tested wrt
ipfilter. If we fail to find maintainer, then a correct decision would be
to remove ipfilter(4) from the base system before 10.0-RELEASE.
This has been discussed in the past. Every time someone came up and said "I'm still using ipfilter!" and the idea to remove it dies with it.
I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter.
One thing that FreeBSD is bad about (and this really applies to many open source
projects) when deprecating something is that the developer and release engineering groups
rarely provide adequate, if any, tools to help users transition and cope with the
deprecation. The fear of deprecation can be largely overcome by giving these users a
clear and comprehensive path forward. Just announcing "ipfilter is going away.
EOM" is inadequate and leads to completely justified complaints from users.
I agree with the deprecation path, but given the amount of changes that
happened in the last 6 months, I'm not even sure ipfilter is working fine in
FreeBSD CURRENT, but I haven't tested it.
So with that said, would it be possible to write some tutorials on how to
migrate an ipfilter installation to pf? Maybe some mechanical syntax docs
accompanied by a few case studies? Is it possible for a script to automate
some of the common mechanical changes? Also essential is a clear document on
what goes away with ipfilter and what is gained with pf. Once those tools are
written, I suggest announcing that ipfilter is available but
deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11.
Certain people will still pitch a fit about it departing, but if the tools are
there to help the common users, you'll be successful in winning mindshare and
general support.
It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm
not sure automated tools exist. I'm also not convinced we need to write them
and I think the issue can be deal with by writing a bunch of examples on how to
do it manually. Then we can give people 1y to switch.
Regards,
--
Rui Paulo
Wow boys, This conversation has gotten way off track. Looking for a
maintainer for ipfilter is totally different than opening the dead
subject of removing ipfilter from the system.
Look at openbsd's pf, its been forked and is now freebsd maintained. New
upstream versions of Ipfilter have always needed tweaking before it can
be included in the base system. If your unsatisfied with the lack of bug
fixes, then ask the author for special permission to create a fork if
his license don't allow it now.
The point is: ipfilter is part of FreeBSD and you are never going to
remove it. Accept that fact.
So look for alternate ways to address your concerns about ipfilter bug
fixs getting applied and/or updating ipfilter to function with vimage or
changes to the Freebsd network stack and kernel APIs.
Finding a maintainer is the purpose of this post, and the solution to
your concerns, so lets stay on subject, OK.
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
