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é 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