linux-kernel - Re: [PATCH 3/3] ahci: st: Add support for ST's SATA IP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140219170037.GK10134@htj.dyndns.org>
Date:	Wed, 19 Feb 2014 12:00:37 -0500
From:	Tejun Heo <tj@...nel.org>
To:	Lee Jones <lee.jones@...aro.org>
Cc:	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	alexandre.torgue@...com, linux-ide@...r.kernel.org,
	hdegoede@...hat.com
Subject: Re: [PATCH 3/3] ahci: st: Add support for ST's SATA IP

On Wed, Feb 19, 2014 at 04:39:37PM +0000, Lee Jones wrote:
> 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.

No policy is perfect and nothing can be decided solely on single
policy.  There of course are trade-offs to make depending on the
specific circumstances.  The problem, here, is that what has been
going on is skewed towards one extreme and has potential to develop
into a fairly large mess if left uncorrected.

The message I've been sending out has been pretty clear.  There are
multiple people duplicating about the same thing in their drivers.
Fortunately, Hans' refactoring is pretty close to completion and
should help simplifying most of them.  I'm not even asking you to do
the bulk of work.  Just take a look at it and help / push if you can.
It may be unfortunate that the circumstances haven't been completely
aligned for your convenience but that's what needs to be done to keep
things sustainable.

This is a collaborative work and what I asked you isn't some
insurmountable amount of extra work.  It's just beyond me that your
response is "it's not fair".  No wonder the whole thing has been
drifting towards mess.  That's not how this works.  Judging from your
linaro address, I assume you have been involved with some upstream
work, how can this possibly be your response?  Such attitude is
actively harmful and has no place in upstream development.

Again, of course, there can be trade-offs.  We sometimes do need to
take termporal hits in maintainability for faster hardware enablement
or whatnot; however, we can't do that without trust that the people
dumping stuff which needs later cleanups would actually help.
Unfortnately, I have close to zero trust given the recent developments
and your "it's not fair, that's not my responsibility" attitude
clearly confirms the conclusion.

So, please take long look at how you perceive upstream development.
It's a collaborative process.  Other people don't owe you by default.

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