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! <http://en.wikipedia.org/wiki/Prometheus> (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 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
