Date: Wed, 7 Jul 2010 14:48:17 -0700 From: Peter Wemm <peter@wemm.org> To: John Baldwin <jhb@freebsd.org> Cc: FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: Cleaning up the CDDL import mess Message-ID: <AANLkTiljyef7QhbU34MjpQ8NXQjUorcvoTRqzH9oeeQo@mail.gmail.com> In-Reply-To: <201007071645.50494.jhb@freebsd.org> References: <B49C7178-FA47-4BBE-BFEF-CB137C114A94@FreeBSD.org> <201007071012.10206.jhb@freebsd.org> <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org> <201007071645.50494.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jul 7, 2010 at 1:45 PM, John Baldwin <jhb@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. =A0It 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. =A0In that sense, it may= make >> > sense to store the vendor DTrace and ZFS bits in separate trees. =A0I'= 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 ve= ndor > branch. > > Yes, we would have to do a vendor import of ZFS and then bootstrap the > mergeinfo. =A0I am just worried that if both ZFS and DTrace live under > vendor/opensolaris there may be weird issues with upgrading one part of t= he > 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 t= he > 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, w= e > 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/dtra= ce. > This is not how we have been doing vendor branches with other external > contributions. > > Yes, I have noticed this as well. =A0It should be fixed as you say that w= e 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. =A0I think it should be fine to fix this by simply co= pying > 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. --=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTiljyef7QhbU34MjpQ8NXQjUorcvoTRqzH9oeeQo>