Re: [PATCH 2/2] Changes to existing files for 0PF FPGA board.

From: Rob Landley
Date: Fri Jun 26 2015 - 23:22:07 EST


On 06/19/2015 05:49 PM, Greg Kroah-Hartman wrote:
> On Fri, Jun 19, 2015 at 04:57:00PM -0500, Rob Landley wrote:
>> On 06/18/2015 12:59 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jun 18, 2015 at 10:19:19AM -0700, Rob Landley wrote:
>>>> Changes to existing files to add 0pf j2 board support.
>>>>
>>>
>>> That's the second worse commit message and subject: line I've read
>>> today.
>>>
>>> And there's no signed off by line.
>>
>> My bad. I've always sucked at filling out paperwork, and I didn't expect
>> this to go in as is. But for the sake of following the official
>> procedures (well, step 11 of of SubmittingPatches, it's not mentioned in
>> any of the 26 steps of SubmitChecklist), here's the requested certification:
>>
>> Signed-off-by: Rob Landley <rob@xxxxxxxxxxx>
>> Reviewed-by: D. Jeff Dionne <jeff@xxxxxxxxxxx>
>
> You didn't do the 26 steps of SubmitChecklist, as step 5 would have
> caught almost all of these issues.

I did not, yes. That's what I was saying above.

(Sorry, probably should have stuck [RFC] on this. I mentioned in the 0/
message that it had several large known todo items. The consensus is I
should do device tree conversion before resubmitting, so working on that.)

>>> And there was no 1/2 patch sent.
>>
>> I sent one, which made it to the archive...
>>
>> http://lkml.iu.edu/hypermail/linux/kernel/1506.2/02539.html
>
> But you didn't cc: me on that, how am I supposed to know?

Ah, I didn't consistently cc: enough people. Got it.

>>> And, most importantly:
>>>
>>>> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
>>>
>>> I don't care about arch/sh/ stuff, why are you sending this to me?
>>
>> $ scripts/get_maintainer.pl j2-oldfiles.patch | grep Greg
>> Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> (maintainer:SERIAL DRIVERS)
>>
>> Sorry, my bad, I was trying to follow the documented procedure.
>> Personally I'd have trimmed the cc: list but filling things out in
>> triplicate seems to be all the rage these days.
>
> No, you need to break your patch up properly, a single patch hitting all
> of these files has never been ok.

So I've been told, yes.

>>> You have a bit of work to do here...
>>
>> As I mentioned in 0/2, yes. But "release early, release often" and all that.
>>
>> (Or did we stop doing that now the Linux Foundation's in charge?
>
> Seriously? It's one thing to cc: a ton of people with a patch that for
> 90% of it, isn't relevant to them, and isn't even something they can do
> anything with.

Ah, I cc:'d too many people. Got it. (Trimming cc: list.)

I'm still getting cc'd on Documentation/ patches, despite bowing out of
messing with that in 2013 and not really doing _any_ kernel stuff in
over a year. Didn't realize it was a thing I should be avoiding.

> It's another thing to rant against those who try to
> point out how to solve your issues.

[Way too long a reply to this bit deleted.]

Let's just say there are a number of historical reasons I've addressed
you as "my nemesis" when we bumped into each other at conferences over
the past few years.

At this point I start my replies to you with a level of exasperation
that's probably not helpful. I'll try to compensate.

>> I'm still stuck in the hobbyist era from back before we had a
>> foundation with committees and a hierarchy where you need to go
>> through proper channels and three dozen patch submission steps in two
>> different files and all that. I'm trying to keep up, but I've always
>> been really bad at bureaucracy...)
>
> There is no such thing here, you know better than that,

We're discussing my failure to correctly follow a 26 step procedure
followed by a second 15 step procedure. Your first objection was that I
didn't sign the right line to provide a mandatory certification
resulting from historical legal action.

You're enforcing these procedures from an executive position within a
hierarchy (tier 3 of 4 in developer/maintainer/subsystem/architect
review cycle, if you approve requests you submit them up the chain for
further approval), on behalf of a foundation that describes itself as a
"consortium" and links to an antitrust policy (and three other policies)
from every page of its website, which got its name during a merger with
a standards body a decade ago.

No such thing as bureaucracy here. Got it.

> stop trying to troll, it's not very becoming.

I wasn't saying bureaucracy is a bad thing, just that I'm bad at it.

Trying to coordinate ten thousand people on six continents working on a
quarter-century old project with a globetrotting annual meeting that's
closed to the public isn't the same as emailing a college student in his
bedroom about the thing he started over the summer that a couple dozen
other people liked. I'm aware of this.

> greg k-h

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/