Cleaning up the CDDL import mess

[John Baldwin]

On Monday, July 05, 2010 2:56:19 pm Rui Paulo wrote:
> Right now we have four locations for CDDL import code:
> 
> 1) vendor-cddl
> 2) vendor/opensolaris
> 3) vendor-sys/opensolaris
> 4) and... HEAD itself.
> 
> 1) vendor-cddl seems to be the first DTrace import and it's probably ready 
to be svn rm'ed because it creates too much confusion. The first thing someone 
who is looking at CDDL source is to probably look at vendor-cddl and I would 
like to avoid this.
> But I don't know what will happen to the mergeinfo in head/cddl and 
head/sys/cddl (I think no harm will be done).
> 
> 2 and 3) These are the correct locations IMHO and I know that jhb did move 
the code here in the past.
> 
> 4) The ZFS code lives in HEAD, unfortunately. I thought the policy was to 
have a vendor import for vendor code so that we could merge *from* upstream 
more easily. I was told that this is being done to some extent in Perforce, 
but I don't know how acceptable this to the community.
> 
> I need to import some DTrace code into 2 and 3, but I would like to svn rm 
vendor-cddl, if there are no objections.

I think it should be fine to remove vendor-cddl.  It would be useful to get
the ZFS bits the correspond to our current ZFS bits committed into the
vendor/opensolaris and vendor-sys/opensolaris trees and to sync up the merge
info.

However, one caveat with the ZFS bits is that we may want to keep ZFS and
DTrace independent in that you don't want to have to force an upgrade of ZFS 
just to get newer DTrace bits and vice versa.  In that sense, it may make 
sense to store the vendor DTrace and ZFS bits in separate trees.  I'm not sure 
how practical that is (e.g. if they share common code).

-- 
John Baldwin