Date: Wed, 7 Jul 2010 16:45:50 -0400 From: John Baldwin <jhb@freebsd.org> To: Rui Paulo <rpaulo@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Cleaning up the CDDL import mess Message-ID: <201007071645.50494.jhb@freebsd.org> In-Reply-To: <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org> References: <B49C7178-FA47-4BBE-BFEF-CB137C114A94@FreeBSD.org> <201007071012.10206.jhb@freebsd.org> <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007071645.50494.jhb>