On Sun, Sep 24, 2017 at 10:39:30PM +0200, Łukasz Majewski wrote:
Hi Tom,
On Sun, Sep 24, 2017 at 06:50:01PM +0200, Marek Vasut wrote:
On 09/24/2017 04:26 PM, Tom Rini wrote:
The following series has been applied. I am posting this for the record.
For the record, I do not believe that using git submodules is a good approach here. We have a small amount of code that we need here, and happily we can leverage infrastructur e from the Linux Kernel.
Speaking of, this is not the first time we have run into problems deviating from the workflow of the kernel. The problems of having large number of warnings, or not stemmed from not just leve raging all of the infrastructure from the kernel. So related, yes, fixes for these warnings should come in, and as always, if they're in the upstream kernel dts as well, they should be fixed there.
So any comments regarding bundling external tools were ignored, even though the discussion was not finished, great.
Furthermore, there was zero time to review this series, it was just applied and posted afterward ? What sort of practice is this ?
Yes. I put on my slightly-less-than-benevolent dictator hat today, and
Linus style? :D Management
It is not my general preference, but yes.
explained my reasoning. I do feel bad that you're rather unhappy with the overall situation, but no, I believe this is the right answer.
Now, there's some follow up further re-syncing with the kernel that could be done (scripts/Makefile.lib/extrawarn can be further re-matched up with the kernel now, but that would have made a larger delta than "just migrate to providing the tool").
But seriously, do we have some kind of road map for this?
I mean if we have copied the dtc tool into u-boot temporarily (until distros catch up) or will it stay with us forever ?
I think long term we'll match what the kernel does and keep synced with upstream, just what we need. I'm thinking I ought to see about pushing a re-sync in the kernel for the next -rc1 there as I know it has been lamented that it hasn't happened in a bit.