Thread (19 messages) 19 messages, 6 authors, 2022-11-30

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 a
If 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help