On 09/24/2017 07:28 PM, Tom Rini wrote:
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 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.
I believe we have a well-established process of submitting patches, getting a review and then applying them. If the head maintainer doesn't follow the process, why should anyone else ?
I believe you should be an example of doing it right, but what you did here is the exact opposite.
The discussion how to solve this problem properly was also unfinished, yet a decision was taken without any community agreement. What is the point of discussing anything on the ML if the decision gets ignored ?
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").