Re: [PATCH v5 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add binding for Apple SoC cpufreq
From: Rob Herring <robh@kernel.org>
Date: 2022-11-30 19:50:29
Also in:
asahi, linux-devicetree, linux-pm, lkml
On Tue, Nov 29, 2022 at 5:28 PM Rob Herring [off-list ref] wrote:
On Wed, Nov 30, 2022 at 12:17:08AM +0900, Hector Martin wrote:quoted
On 29/11/2022 23.34, Krzysztof Kozlowski wrote:quoted
On 29/11/2022 15:00, Hector Martin wrote:quoted
On 29/11/2022 20.36, Ulf Hansson wrote: Please, let's introspect about this for a moment. Something is deeply broken if people with 25+ years being an arch maintainer can't get aIf arch maintainer sends patches which does not build (make dt_binding_check), then what do you exactly expect? Accept them just because it is 25+ years of experience or a maintainer? So we have difference processes - for beginners code should compile. For experienced people, it does not have to build because otherwise they will get discouraged?I expect the process to not be so confusing and frustrating that a maintainer with 25+ years of experience gives up. That the bindings didn't pass the checker is besides the point. People say the Linux kernel community is hostile to newbies. This issue proves it's not just newbies, the process is failing even experienced folks.IME, a lack of response is a bigger issue and more frustrating.quoted
On that specific issue, any other functional open source project would have the binding checks be a CI bot, with a friendly message telling you what to do to fix it, and it would re-run when you push to the PR again, which is a *much* lower friction action than sending a whole new patch series out for review via email (if you don't agree with this, then you're not the average contributor - the Linux kernel is by far the scariest major open source project to contribute to, and I think most people would agree with me on that).We could probably add a $ci_provider job description to do that. In fact, I did try that once[1]. The challenge would be what to run if there's multiple maintainers doing something. Otherwise, it's a maintainer creating their own thing which we have too much of already.
Actually, turns out this pretty much already exists with my CI. I just had to turn on merge requests on the project. If anyone actually uses it, I'll have to tweak it to not do 'make dtbs_check' because that is really slow. And this all runs on my machines, so that is another issue. It already is just running it for patches on the list (which is a different CI job). Just create a MR here: https://gitlab.com/robherring/linux-dt/-/merge_requests Rob _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel