From: tj@kernel.org (Tejun Heo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 3/3] ahci: st: Add support for ST's SATA IP
Date: Wed, 19 Feb 2014 12:26:02 -0500 [thread overview]
Message-ID: <20140219172602.GL10134@htj.dyndns.org> (raw)
In-Reply-To: <20140219163937.GI10504@lee--X1>
A few more things just in case.
On Wed, Feb 19, 2014 at 04:39:37PM +0000, Lee Jones wrote:
> It tells me that Hans has more spare time than I do.
This is the crux of the problem, isn't it? The party who is creating
load should also partake in and invest resource into making the
infrastructure for it. What I can't understand is how one can claim
"unfairness" at having to contribute to such effort when that is
clearly the party which is the primary beneficiary of the added load.
If you have *any* mature sense of fairness, not this childish "it's
not going my way", the irony should be clear to you.
> This work would even be something I'd be interested in helping out
> with - even in my own time, but the way you speak to people doesn't
> exactly inspire them to go out of my way to work with you does it?
Given the circumstances, I don't think depending on good wills of the
involved parties is a viable strategy and wanted to make it clear that
the responsibility of chipping in for long term maintainability is on
everyone who wants to make use of the code base. This is beyond good
will. It's the fundamental sharing of responsibility for
sustainability. I'd love to have good will but I can't build that on
top of a notion as rotten as "it's not fair, it's not my
responsibility".
> Again, that's not what I said. It's great that your subsystem is being
> improved, but insisting that anyone who submits new code to rebase
> on top of some development patches which only exist in mail form, and
> refusing to take patches until they do so doesn't seem right to me.
If I apply your patch now, Hans has one more driver to worry about in
doing the work that he himself isn't directly benefiting from but
everybody needs. In what world is that fair?
So, sorry about going f bomb on you, but you shouldn't be thinking
what you're thinking. There's some serious misguidance going on
there.
--
tejun
next prev parent reply other threads:[~2014-02-19 17:26 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 12:56 [PATCH 1/3] ahci: st: Provide DT bindings for ST's SATA implementation Lee Jones
2014-02-17 12:56 ` [PATCH 2/3] ARM: DT: STi: Add DT node for ST's SATA device Lee Jones
2014-02-17 12:56 ` [PATCH 3/3] ahci: st: Add support for ST's SATA IP Lee Jones
2014-02-18 23:36 ` Tejun Heo
2014-02-19 8:30 ` Lee Jones
2014-02-19 14:04 ` Tejun Heo
2014-02-19 15:01 ` Lee Jones
2014-02-19 15:06 ` Tejun Heo
2014-02-19 15:23 ` Lee Jones
2014-02-19 15:36 ` Tejun Heo
2014-02-19 16:39 ` Lee Jones
2014-02-19 17:00 ` Tejun Heo
2014-02-19 17:24 ` Lee Jones
2014-02-19 17:26 ` Tejun Heo [this message]
2014-02-19 17:40 ` Lee Jones
2014-02-19 18:06 ` Tejun Heo
2014-02-19 11:54 ` Hans de Goede
2014-02-19 12:14 ` Lee Jones
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=20140219172602.GL10134@htj.dyndns.org \
--to=tj@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).