Re: Ipfilter pre-Vendor Import Issue

  Cy,

On Fri, Jul 05, 2013 at 11:38:21AM -0700, Cy Schubert wrote:
C> > What I'd prefer to see is the following:
C> > 
C> > - commit new ipfilter untouched to vendor-sys/ipfilter
C> > - nuke sys/contrib/ipfilter
C> > - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter
C> 
C> Having ipfilter in one place instead of two (vendor and vendor-sys) makes a 
C> lot more sense.
C>
C> I suppose we could put ipfilter's kernel components in sys/netpfil but what 
C> about the userland sources? Also see my reply below regarding keeping it in 
C> contrib.

IMO, it is possible to keep a bulk checkout of ipfilter in vendor/ipfilter,
but merge kernel files separately to sys/netpfil/ipfilter, and separately
merge userland files to appropriate place.

C> > In future imports do:
C> > 
C> > - commit newer ipfilter to vendor-sys/ipfilter
C> > - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter
C> > 
C> > What's the reason to keep code in contrib?
C> 
C> The reason to keep ipftilter in contrib is to maintain consistency with 
C> other contributed software such as bind, nvi, sendmail, pf, and a host of 
C> other notable software we don't maintain ourselves. Maintaining consistency 
C> with other contributed software should probably be maintained. I'm open to 
C> moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as 
C> long as consistency is maintained across the board.
C> 
C> Do you think we should put the userland sources also in the same location 
C> or should we maintain a similar separation we do today? I'm open to both 
C> however I'd prefer keeping all vendor software (kernel and userland) in one 
C> location.

The BSD license allows us to put the code into FreeBSD w/o any separation.

So the question is: what is more handy to us?

What do we actually gain having contrib/ipf, assuming we got vendor branch
already?

What we lose is: 
- more complex Makefiles
- more complex hacking: edit files in one place, run make in other

-- 
Totus tuus, Glebius.