I only really need one question answered in honesty;
I personally think that by forking our own version of PF we have
essentially made something totally different to what everyone wants to
use. Which is fine, but because of that development of new features have
dropped behind.
If we had kept up with OpenBSD's version even if we trailed it by one
MAJOR release; at least part of the development would have been done.
So now we end up in a situation where we have these firewalls,
IPFW2,ipf,pf(modded) and users wanting the newer features of OpenBSD's pf.
So timewise the fork of pf may have actually cost more in time rather than
less.
I don't however think the 'solution' to the problem is just to say no to
the userbase by not even trying to port across the newer pf. I think we
should look at bringing it across, slowly and seeing what the uptake is
like; in a few MAJOR releases we can start to look at which of the
firewalls realistically are not used that much and should be deprecated.
On Wed, 21 Nov 2012 15:20:19 -0000, Ermal Luçi <e...@freebsd.org> wrote:
On Wed, Nov 21, 2012 at 3:52 PM, Gleb Smirnoff <gleb...@freebsd.org>
wrote:
On Wed, Nov 21, 2012 at 03:44:13PM +0100, Ermal Lu?i wrote:
E> Cherry-picking would be when tehre is reasonable similarities.
E> Also another argument to do this would be simplicity on locking as
well
as
E> i told you when you started the changes.
You were wrong. OpenBSD doesn't move towards SMP model. Locking more
recent pf is not simplier, but the opposite.
I am sorry but you are asking arguments i already have given you.
You didn;t listen once and i do not expect this time as well.
E> Though i am open to work together on this to merge the new syntax
thorugh a
E> whole bulk merge rather than cherry-pick.
How many bugs have you closed after the previous bulk import? Why should
we expect anything good from new import if the previous one was a PITA?
Well you have used it for your work so it was not so PITA.
Most of the ones you closed had message 'This is to old to be true'; 'I
have re-written PF and this should be fixed'.
And still I don't see any answer on the question: what exact features or
perfomance improvements are we going to obtain from "the new pf"?
See above.
E> You already have 'broken' some functionality as if-bound in FreeBSD
10.x so
Is there any PR filed on that? I didn't even receive a mail about that.
I really do not think you do the right approach or the right
communication
on this.
Sorry for replying to you ;).
--
Totus tuus, Glebius.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
_______________________________________________
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"
