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