Re: [PATCH 3/3] dtc: Update to version 1.6.1

[David Gibson]

On Fri, Oct 01, 2021 at 01:41:04PM +0200, Thomas Huth wrote:
> On 01/10/2021 11.44, Daniel P. Berrangé wrote:
> > On Fri, Oct 01, 2021 at 10:37:51AM +0100, Peter Maydell wrote:
> > > On Fri, 1 Oct 2021 at 10:10, Daniel P. Berrangé <berrange@redhat.com> 
> > > wrote:
> > > > 
> > > > On Thu, Sep 30, 2021 at 09:10:12AM +0200, Thomas Huth wrote:
> > > > > On 27/08/2021 14.09, Thomas Huth wrote:
> > > > > > The dtc submodule is currently pointing to non-release commit. It's 
> > > > > > nicer
> > > > > > if submodules point to release versions instead and since dtc 1.6.1 
> > > > > > is
> > > > > > available now, let's update to that version.
> > > 
> > > > Most of our supported platforms don't have version 1.6.1 available.
> > > > 
> > > > As a general goal IMHO we should be seeking to eliminate bundling of
> > > > 3rd party modules that are commonly available in distros. We've
> > > > carried dtc for a hell of a long time, and if we keep updating our
> > > > submodule we'll keep relyin on new features, and never be able to
> > > > drop it because it will always be newer than what's in the distros.
> > > > 
> > > > So personally I think we should never again update dtc and capstone
> > > > modules. If we want to take adbantage of new features, then do that
> > > > through conditional compilation, as we do for any of the other 3rd
> > > > party libraries consumed.
> 
> I basically agree, especially for capstone. But for dtc, that also means
> that we cannot compile certain target boards if its not available ... that's
> somewhat more ugly than if there is just a missing backend feature ... but I
> guess it's still ok. Users could always install a recent libfdt first.
> 
> > > I agree in general, but (per the commit message here) our dtc
> > > submodule is currently pointing at some random not-a-release
> > > commit in upstream dtc. We should at least move forward to
> > > whatever the next released dtc after that is, before we say
> > > "no more dtc updates".
> > 
> > Yep, if we want to fix it onto an official version tag, that's
> > OK, just not jumping right to very latest version.
> 
> That was the intention here. Accidentally, the first release tag after the
> commit that we are currently using, is version 1.6.1, which also happens to
> be the latest version, too.

Note that while I think this is a good idea, there's no real stability
difference between official releases and any random git commit.  I
tend to make releases when somebody complains that there's a new
feature or fix they want that isn't yet in a numbered release.  They
don't get any additional testing beyond the build-in make check which
I also run on every commit.. and which is generally fine, because the
coverage is pretty good (a rather contrained problem space makes that
relatively 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

signature.asc
Description: PGP signature