From owner-freebsd-arch@FreeBSD.ORG Wed Jul 7 22:16:34 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 93DFB106564A for ; Wed, 7 Jul 2010 22:16:34 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 535A28FC0A for ; Wed, 7 Jul 2010 22:16:34 +0000 (UTC) Received: by vws6 with SMTP id 6so264657vws.13 for ; Wed, 07 Jul 2010 15:16:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.204 with SMTP id kh12mr4429395qcb.191.1278539297219; Wed, 07 Jul 2010 14:48:17 -0700 (PDT) Received: by 10.229.238.10 with HTTP; Wed, 7 Jul 2010 14:48:17 -0700 (PDT) In-Reply-To: <201007071645.50494.jhb@freebsd.org> References: <201007071012.10206.jhb@freebsd.org> <04991DD5-F22D-4F4E-8E33-89DE566DFB30@FreeBSD.org> <201007071645.50494.jhb@freebsd.org> Date: Wed, 7 Jul 2010 14:48:17 -0700 Message-ID: From: Peter Wemm To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Arch Subject: Re: Cleaning up the CDDL import mess X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 22:16:34 -0000 On Wed, Jul 7, 2010 at 1:45 PM, John Baldwin 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