Cleaning up the CDDL import mess

[Peter Wemm]

On Wed, Jul 7, 2010 at 1:45 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Wednesday, July 07, 2010 11:20:38 am Rui Paulo wrote:
>> 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.
>
> Yes, we would have to do a vendor import of ZFS and then bootstrap the
> mergeinfo.  I am just worried that if both ZFS and DTrace live under
> vendor/opensolaris there may be weird issues with upgrading one part of the
> vendor tree and not the other, but perhaps it will work ok.
>
>> 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.
>
> Yes, I have noticed this as well.  It should be fixed as you say that we copy
> the FreeBSD changes in head to the original path in the vendor source so we
> can do meaningful merges in the future and generate useful diffs relative to
> the vendor sources.  I think it should be fine to fix this by simply copying
> our version of the file over and committing it as a change in head.
>
> --
> John Baldwin

Much of this stuff is the way it is because there was no practical way
to force cvs2svn into doing it a more convenient way.  It needed 1:1
mappings between cvspath:branch<->namespace, so things that got 'cvs
import'ed inside src/sys couldn't be coerced into sharing a common
destination with other cvspath:branch trees.

By all means, move it to where it does the most good.

-- 
Peter Wemm - peter at wemm.org; peter at FreeBSD.org; peter at yahoo-inc.com; KI6FJV
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell