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é <berra...@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
