[HEADS UP] merging projects/pf into head

[Gleb Smirnoff]

  Ermal,

On Fri, Sep 07, 2012 at 10:02:47AM +0200, Ermal Lu?i wrote:
E> > I won't keep OpenBSD-pf and FreeBSD-pf in parallel in FreeBSD. The OpenBSD-pf
E> > port have proved to be poorly maintained. After last import that was made
E> > by you, at least the following regressions were introduced:
E> >
E> > - enabling pfsync immediately panics
E> > - kldunload pf.ko immediately panics
E> >
E> Going to personal attacks shows your willing to discuss as civilized person.
E> Though that does not mean anything in the sense that bugs are there to
E> be found by testers.

  Subtle and difficult to catch bugs are to be found by testers. Bugs that
show up immediately after a subsystem had been started, shouldn't make their
way to SVN.

  If I even agree with you that immediate crash on enabling pfsync should had
been found not by you, but by a random FreeBSD-CURRENT user, then the next
question would be: who is responsible to fix it? Let's look... A random user
hits the panic and submits kern/159029. Who did fix that? Why not you?
And here I am not picking at a certain exclusive bug that you missed. The
bulk import of pf-4.5 was followed by dozens of bug fixes, most of which
were done by bz@, pluknet@ and me.

E> If you have not found out yet, testers for something that people take
E> for granted as firewalls are scarce in general.

  Mistake. There are some people, who run my branch prior to its merge
to head. More people then I expected.

E> Something that has been learnt from history is that people want
E> software X to be compatible with software Y from where it came from.
E> They are not interested on X to use the same rules but hey its
E> different from Y because of Z.

  From what I see, there is a another rule in FreeBSD. FreeBSD-N should
be compatible not with OpenBSD-M, but with FreeBSD-(N-1). And idea
to bring new syntax is breaking this rule. Haven't this been discussed
before importing pf-4.5?

E> > Hey, these aren't a difficult to catch bugs, that require special setup
E> > or weeks of catching a race condition. This is basic functionality, and panics
E> > are evidence that code wasn't tested properly. Okay, we all ain't saints, and
E> > people do errors. But why wasn't you promptly fixing these errors? You just
E> > dropped many Kb of code into SVN (via bz@) and then disappeared. Have you closed
E> > at least on PR in GNATS?
E> 
E> AFAIK i fixed any reported panics on freebsd-pf list.

False. During the 9.0-RELEASE release cycle, linimon@ had thoroughly assigned
all new pf bugs to freebsd-pf@ list. You took none of them.

E> I did not even go the PR route because i had other plans which
E> $DAYLIFE/WORK still have not allowed to pursue.
E> Furthermore, there is nothing guaranteeing that you will not do the
E> same, or have the same bugs in different fashion, i.e. VIMAGE/VNET?!.
E> Just because you are doing work right now and are the only one behind
E> these changes, AFAIK, does not mean its a long term partnership
E> or that you will provide better SLA on this part.

Agreed. I may go away from pf in future. But in this case I won't pretend
that I'm still its maintainer and block other people willing to work.

-- 
Totus tuus, Glebius.