Cleaning up the CDDL import mess

[Rui Paulo]

On 7 Jul 2010, at 15:12, John Baldwin wrote:

> 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).

ZFS doesn't use any code in the vendor area. It's all imported "by hand" in Perforce and then merged to HEAD, "by hand" too. So, unless the ZFS team wants to start using real vendor imports instead of what they have been doing, there's no such problem as "common code".

If you are advocating that we should do a vendor import of ZFS, I agree. If you're just saying that you want to fix the mergeinfo in ZFS, that is not going to be enough because most of the ZFS code is in HEAD, not in the vendor branch.

Regarding DTrace, a lot of it has been copied to HEAD without a proper vendor import, but some of bits were vendor imported, as you may know.

What I really wanted to see for DTrace was a real vendor import of all the necessary DTrace code, merged all to cddl/contrib and then we would edit cddl/contrib to port DTrace to FreeBSD (since DTrace is already ported, we would just copy the stuff outside cddl/contrib to cddl/contrib).
As an example, consider the DTrace module. We have sys/cddl/contrib with several headers and whatnot, but the real code lives in sys/cddl/dev/dtrace. This is not how we have been doing vendor branches with other external contributions. 

Of course it may be too late now.

Regards,
--
Rui Paulo