public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rob Landley <rob@landley.net>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] Changes to existing files for 0PF FPGA board.
Date: Fri, 26 Jun 2015 22:21:56 -0500	[thread overview]
Message-ID: <558E16D4.6010605@landley.net> (raw)
In-Reply-To: <20150619224958.GA27925@kroah.com>

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@landley.net>
>> Reviewed-by: D. Jeff Dionne <jeff@uclinux.org>
> 
> 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@linuxfoundation.org> (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

  reply	other threads:[~2015-06-27  3:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18 17:19 [PATCH 0/2] 0pf-j2 (sh2-compatible open hardware) FPGA board support Rob Landley
2015-06-18 17:19 ` [PATCH 1/2] New files for 0PF FPGA board Rob Landley
2015-06-19  7:47   ` Geert Uytterhoeven
2015-06-18 17:19 ` [PATCH 2/2] Changes to existing " Rob Landley
2015-06-18 17:59   ` Greg Kroah-Hartman
2015-06-18 19:02     ` Steven Rostedt
2015-06-19 21:57     ` Rob Landley
2015-06-19 22:49       ` Greg Kroah-Hartman
2015-06-27  3:21         ` Rob Landley [this message]
2015-06-18 19:36   ` Geert Uytterhoeven
2015-06-19 22:11     ` Rob Landley
2015-06-20  8:00       ` Geert Uytterhoeven
2015-06-20 20:13         ` Rob Landley
2015-06-20 20:48           ` Geert Uytterhoeven
2015-06-22  4:26           ` Yoshinori Sato

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=558E16D4.6010605@landley.net \
    --to=rob@landley.net \
    --cc=akpm@linux-foundation.org \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox