From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ext-ch1gw-5.online-age.net (ext-ch1gw-5.online-age.net [64.37.194.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "ext-ch1gw.online-age.net", Issuer "Savvis Communications Root CA" (not verified)) by ozlabs.org (Postfix) with ESMTP id 418FBDDDFB for ; Thu, 1 Nov 2007 00:48:50 +1100 (EST) Received: from int-ch1gw-6.online-age.net (int-ch1gw-6 [3.159.232.70]) by ext-ch1gw-5.online-age.net (8.13.6/8.13.6/20051111-SVVS-TLS-DNSBL) with ESMTP id l9VCocPO024580 for ; Wed, 31 Oct 2007 08:50:43 -0400 (EDT) Received: from alpmlef01.e2k.ad.ge.com (int-ch1gw-6 [3.159.232.70]) by int-ch1gw-6.online-age.net (8.13.6/8.13.6/20050510-SVVS) with ESMTP id l9VCn8Pp026194 for ; Wed, 31 Oct 2007 08:49:13 -0400 Message-ID: <47287A10.2030304@ge.com> Date: Wed, 31 Oct 2007 08:50:24 -0400 From: Jerry Van Baren MIME-Version: 1.0 To: Jerry Van Baren , Jon Loeliger , Kumar Gala Subject: Re: libfdt as its own repo and submodule of dtc? References: <4727665E.1070109@ge.com> <20071030234011.GE2784@localhost.localdomain> In-Reply-To: <20071030234011.GE2784@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Cc: linux-ppc list , u-boot-users List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , David Gibson wrote: > On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote: >> Jon Loeliger wrote: >>> So, like, the other day Kumar Gala mumbled: >>>> Jon, >>>> >>>> It seems like have libfdt as a unique git repo that is a submodule of >>>> the things that need it (dtc, u-boot, etc.) might make some sense and it >>>> easier for the projects that need to pull it in. >>>> >>>> Is this something you can take a look at? (or have other ideas on). >>> I would be fine with making libfdt a git repository separate >>> from the DTC repository if that makes it easier to integrate >>> it with other projects. > > I don't think it's a good idea to make dtc and libfdt entirely > seperate repositories (again). Being able to use both together in > their combined testsuite is very useful (libfdt is used to check trees > generated by dtc, dtc is used to generate example trees for libfdt > testing). > > I'm not sure how submodules/subrepositories work so I don't know if > that makes sense. > >> That sounds like a good idea to me. I would really prefer pulling patches >> out of a libfdt repo into the u-boot repo rather than trying to kerchunk >> upgrade lumps. While we can do this with a dtc repo, it potentially makes >> it a lot more difficult. > > I don't think upgrading embedded copies by diff is a good way to go. > The upgrade method I had in mind was to pull out a whole new copy of > libfdt, drop that into the embedding project verbatim and generate a > new diff there in whatever their source tracking system is. I set out > the repository to make this easy. I looked at this some more last night and thought about it a bit and still am conflicted... Pros for pulling/applying diffs/patches ---- * History is preserved, including "signed-off-by" lines. This is a *major* positive. * Individual patches are small, allowing better publishing and reviewing. This is a double-edged sword (see Cons). Cons ---- * Uninteresting files may be touched by the patches, causing patch breakage. An example of this is the original libfdt had a test subdirectory (subsequently promoted to the same level as ./libfdt and generalized to be a dtc+libfdt test suite). When I grabbed the original snapshot of libfdt, I did not pick up the test suite, so any patches that include the test suite (many older ones) will have problems. * Tracking patches in a different repository and applying them is a lot of WORK. * Publishing patches for review on the u-boot list has marginal benefit. If someone on the u-boot list has a problem with a patch, *I'm* not at all interested in being an intermediary carrying the flames across two mail lists between David, who isn't on the u-boot list, and Joe Uboot, who isn't on the linuxppc-dev list. Hoo boy, would that be an untenable situation! (I prefer to have alcohol eat my liver, not an eagle, thankyouverymuch.) ---- At this point, I'm inclined to do a "big bang" update to the (nearly) current state, thanks to Kumar, and see how it works to apply patches to incrementally move it forward. Hmmm, I need to get back to the topic... the bottom line is, at this point I don't see any major benefit of having libfdt in a separate git repo. I don't see it as making my task significantly easier and would just add hassle to Jon and David's life. Best regards, gvb