On Fri, Jul 28, 2017 at 12:46:25AM +0300, Pantelis Antoniou wrote:
> Hi Frank,
>
> On Thu, 2017-07-27 at 13:22 -0700, Frank Rowand wrote:
> > Hi Pantelis,
> >
> > Keep in mind one of the reasons Linus says he is very direct is to
> > avoid leading a developer on, so that they don't waste a lot of time
> > trying to resolve the maintainer's issues instead of realizing that
> > the maintainer is saying "no". Please read my current answer as being
> > "no, not likely to ever be accepted", not "no, not in the current form".
> >
> > My first reaction is: no, this is not a good idea for the Linux kernel.
>
> This has nothing to do with the kernel. It spits out valid DTBs that the
> kernel (or anything else) may use.
[snip]
> > - experiment with changes to DTB format for overlays?
>
> The DTB format never had to change. It's a simple key/value store with a
> few funny bits.
Except you are proposing changing it by adding type information.
>
> > - get patches to dtc accepted?
> >
>
> Bingo.
Ok. So I've made a number of snide remarks in this thread about the
design of the overlay format. For that, I apologise - I try not to be
passive aggressive, but I frequently fail, and I've had various
unrelated reasons to be grumpy lately.
Let me instead be bluntly rude: if you want patches accepted into dtc
faster, write better patches.
I'm aware that I tend to be overly nitpicky. That's another habit I
try to avoid, but often fail (doesn't help I'm a qemu developer and
the qemu community is also very nitpicky about patches). But that's
not the only problem.
Your patches have frequently had sloppy errors: not being careful
about buffer limits, inaccurate comments, not matching existing
similar code when it makes sense to do so. That's in addition to the
harder to quantify problems of showing insufficient thought on "is
this the best/simplest way to solve this problem" at each level.
Errors in internal implementation can be fixed or cleaned up later,
but best to avoid as many as possible first time round. Errors in
interfaces cause much more pain, and nearly everything about dts and
dtb is an interface. It's worth trying hard to avoid mistakes.
When I make suggestions about changes you frequently just re-iterate
why you want the feature you're trying to implement. That's not at
issue, what I need is either to make the suggested change, or to make
a case as to *why* your original approach is a better way of achieving
the goal.
All the above means the patches tend to go through many iterations
befoire merge. But, it's more than that.
1. Because of the above, I'm inclined to review your patches in
detail, which takes longer
2. Because of (1), reviewing your patches is more work, which makes
me procrastinate about it longer.
3. Because of all the above, I'm less willing to ignore minor errors
(or correct them myself).
Well, there it is. I may well regret sending this later.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
Attachment:
signature.asc
Description: PGP signature
