Re: Ipfilter pre-Vendor Import Issue

In message <20130705084649.GC67810_at_FreeBSD.org>, Gleb Smirnoff writes:
>   Cy,
> 
> On Thu, Jul 04, 2013 at 03:10:14PM -0700, Cy Schubert wrote:
> C> Unfortunately it doesn't work any more. Here is what svn spit out at me.
> C> 
> C> slippy$ cd $MY_WORK_DIR/current/contrib/ipfilter
> C> slippy$ svn merge --record-only file:///tank/wrepos/wsvn/base/vendor/ipfil
> te
> C> r/dist_at_252548
> C> svn: E205000: Try 'svn help merge' for more information
> C> svn: E205000: Source and target must be different but related branches
> C> svn: E205000: Source and target have no common ancestor: 
> C> 'file:///tank/wrepos/wsvn/base/vendor/ipfilter/dist_at_252548' and 
> C> '._at_unspecified'
> C> slippy$ 
> 
> AFAIU, the problem is that current contrib/ipfilter was never merged
> from vendor/ipfilter. So, actually we are dealing with a first import
> (from subversion viewpoint), not n-th.

That's unfortunate. 

> 
> What I'd prefer to see is the following:
> 
> - commit new ipfilter untouched to vendor-sys/ipfilter
> - nuke sys/contrib/ipfilter
> - svn copy vendor-sys/ipfilter to sys/netpfil/ipfilter

Having ipfilter in one place instead of two (vendor and vendor-sys) makes a 
lot more sense.

I suppose we could put ipfilter's kernel components in sys/netpfil but what 
about the userland sources? Also see my reply below regarding keeping it in 
contrib.

> 
> In future imports do:
> 
> - commit newer ipfilter to vendor-sys/ipfilter
> - svn merge vendor-sys/ipfilter to sys/netpfil/ipfilter
> 
> What's the reason to keep code in contrib?

The reason to keep ipftilter in contrib is to maintain consistency with 
other contributed software such as bind, nvi, sendmail, pf, and a host of 
other notable software we don't maintain ourselves. Maintaining consistency 
with other contributed software should probably be maintained. I'm open to 
moving all packet filters, e.g. ipfw, pf, and ipfilter into sys/netpfil as 
long as consistency is maintained across the board.

Do you think we should put the userland sources also in the same location 
or should we maintain a similar separation we do today? I'm open to both 
however I'd prefer keeping all vendor software (kernel and userland) in one 
location.



-- 
Cheers,
Cy Schubert <Cy.Schubert_at_komquats.com>
FreeBSD UNIX:  <cy_at_FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.