Message-ID: <ff4273fe-e57f-8ce0-be60-b6b05386ffb4@marcan.st>
Date:   Wed, 30 Nov 2022 01:05:01 +0900
From:   Hector Martin <marcan@...can.st>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Ulf Hansson <ulf.hansson@...aro.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Stephen Boyd <sboyd@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Mark Kettenis <mark.kettenis@...all.nl>, asahi@...ts.linux.dev,
        linux-arm-kernel@...ts.infradead.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v5 2/4] dt-bindings: cpufreq: apple,soc-cpufreq: Add
 binding for Apple SoC cpufreq

On 30/11/2022 00.46, Krzysztof Kozlowski wrote:
> On 29/11/2022 16:17, Hector Martin wrote:
>> When it takes 10 times more man-hours to upstream a driver than to
>> reverse engineer and write it with zero documentation, never mind the
>> calendar time it takes, something is very wrong. 
> 
> Yes, that's a point. Yet we (community) still have another goal here
> than the pure goal of submitter. The submitter wants its stuff upstream.
> Therefore this upstreaming effort is for submitter a bit wasted (as I
> agree that reverse-engineering should be the biggest task).
> 
> However the community (expressed maybe mostly as maintainers) wants
> something which will be maintainable and usable also for others, not
> only for patch submitters.
> 
> Indeed maybe 10x difference between writing code and upstreaming is
> something to improve, but please do not forget that the concept is here
> to be able to manage this big codebase.

You're misunderstanding me here. The problem isn't the goal of keeping
things maintainable. The problem is that the process involved makes the
entire experience take much, much longer than it should. A more
efficient process could maintain the same (actual) code quality with a
lot less time wasted for everyone, both in process issues and in
bikeshedding details that don't actually increase code quality.

>> I actively dread
>> submitting new drivers to new subsystems or some existing ones now. How
>> much pain will the next one be? Will I be asked to move files around 3
>> times? Spend 4 rounds bikeshedding the DT schema? Think it's finally
>> ready only for someone to show up and ask to change a major part of the
>> design at the last minute?
>>
>> And this all when we're actually submitting code of decent quality (I
>> think I have enough experience not to submit crap most of the time). Now
>> imagine how much worse this all is for a newbie who submits a
>> well-intentioned but definitely not up to standard patch. There's a huge
>> chance they'll give up before ever getting the submission through.
> 
> You say this like any newbie should be able to send a patch and get it
> accepted right away, regardless of actually what is in that patch (not
> up to standard). It's not newbie's right. No one said it's easy and fast
> process... If you want easy and fast, do JavaScript... If you want to
> make it easier and faster in the kernel, then we need more reviewers and
> maintainers. Somehow many, many people want to send patches, but not
> that many want to review them.

Again, I'm not saying the bad code should go in. I'm saying the
*process* is so frustrating that most newbies will give up before the
code has a chance to evolve from bad to good and go in. The solution
isn't to let more bad code in, it's to make the process less painful.

And yes, some of it does mean either relaxing style rules or just
adopting a formatter, because let's face it: complaints that a line is
81 characters instead of 80 don't *actually* increase code quality to
any measurable extent, they just waste everyone's time, and if that
level of style pickiness is desired, that's what formatters are for.

I have personal experience with this with the Asahi Linux bootloader
(m1n1). We use a formatter for C; the CI tells people when they have to
run `make format` to fix their style and that solves all our C
formatting issues (incidentally, we also have a CI bot to check for
S-o-b lines - very handy). We don't use a formatter for Python, and as a
result, I don't impose overly strict rules on things like exactly how
many lines of whitespace should exist between functions or exactly how
expression continuations should be indented or what the maximum line
length is (within reason), because code doesn't have to look like it was
written by a homogeneous robot to still be completely understandable and
readable to humans using modern editing tools, and trying to teach every
contributor my own personal style (which isn't even 100% consistent, I'm
not a robot either!) would be a waste of my and their time. Most
contributors are capable of defaulting to a readable coding style
similar to the rest of the code around it, and it's rare I have to tell
someone to fix the formatting because something is clearly wrong (like
blatantly inconsistent block indentation).

- Hector

Powered by blists - more mailing lists