libfdt as its own repo and submodule of dtc?

libfdt as its own repo and submodule of dtc?

[Kumar Gala]

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).

- k

Re: libfdt as its own repo and submodule of dtc?

[Jon Loeliger]

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.

jdl

Re: libfdt as its own repo and submodule of dtc?

[Jerry Van Baren]

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.
> 
> jdl

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.

gvb

Re: libfdt as its own repo and submodule of dtc?

[David Gibson]

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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: 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

Re: libfdt as its own repo and submodule of dtc?

[David Gibson]

On Thu, Nov 01, 2007 at 01:55:30AM -0500, Kumar Gala wrote:
> 
> On Oct 30, 2007, at 6:40 PM, 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.
> 
> I believe submodules will accomplish this (at least from what I can  
> tell).

I'm not too keen on using a git feature that's more recent than the
git in most distros.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: libfdt as its own repo and submodule of dtc?

[Kumar Gala]

On Oct 30, 2007, at 6:40 PM, 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.

I believe submodules will accomplish this (at least from what I can  
tell).

- k

Re: libfdt as its own repo and submodule of dtc?

[Jon Loeliger]

On Wed, 2007-10-31 at 17:56, David Gibson wrote:

> I'm not too keen on using a git feature that's more recent than the
> git in most distros.

I'm going to consider this argument null and void on two fronts:

You don't use git for patch generation and submission anyway.

The Linux Community happily embraced and used early
versions of git, installing it themselves if needed,
long before it was available in _any_ distro.

Thanks,
jdl

Re: libfdt as its own repo and submodule of dtc?

[David Gibson]

On Thu, Nov 01, 2007 at 09:04:42AM -0500, Jon Loeliger wrote:
> On Wed, 2007-10-31 at 17:56, David Gibson wrote:
> 
> > I'm not too keen on using a git feature that's more recent than the
> > git in most distros.
> 
> I'm going to consider this argument null and void on two fronts:
> 
> You don't use git for patch generation and submission anyway.

True.  It wasn't clear to me whether using this git-submodule thing
would also affect pulling.

> The Linux Community happily embraced and used early
> versions of git, installing it themselves if needed,
> long before it was available in _any_ distro.

I don't think this is a comparable situation.  For one, dtc does not
have the clout of Linux.  For another, at the time there was hardly
anything in the way of suitable solutions that were out there in
distros.  That's not the case now - we can do nearly everything we
want with the git in recent distros, I don't think there's call to
require a newer version for one extra feature.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson