libfdt as its own repo and submodule of dtc?

[Jerry Van Baren]

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