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: <20140219153624.GI10134@htj.dyndns.org>
Date:	Wed, 19 Feb 2014 10:36:24 -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 03:23:36PM +0000, Lee Jones wrote:
> Since when has maintaining core code been the responsibility of the
> leaf driver developers? If you're aware that the core code is
> sub-standard then it's you who should be fixing it.

No, there isn't this clear divide between core and the leaf
developers.  People working on the "core" don't just grow off the
ground.  You can't just go around piling mess around claiming that
it's not your responsbility and then expect someone else to clean up
after you.  How can that be *possibly* sustainable?

> I think it's great that forward thinking developers like Hans take on
> challenges to improve subsystems which are lacking in one way or

Yeah, which happened only because I pushed back and Hans isn't even
paid to do it.  Doesn't that say something?  Nobody is actually
helping Hans' work.  Not at all, nada, zilch.  Just complain when
directed towards it.

> another, but holding back other development while this process is
> ongoing is fundamentally wrong. Especially in this case where you're
> still actively reviewing/NACKing the core changes.
> 
> Changes to APIs should either support backward-capability or change all
> effected drivers. I haven't been able to apply the patches yet, so I
> can't tell which one of these holds true, but I believe it's the
> former. In which case any new driver using the _current_ (not old)
> API should fold neatly in. I've even offered to convert to the new API
> once it's Mainlined. How can I say fairer than that?
> 
> Finally, do try and stay at least a little bit professional on the
> MLs. That sort of disrespectful, rude behaviour may be how you guys do
> it at Redhat, but most will think it's nothing more than childish.

If you want me to be respectful towards you, don't be a crybaby
screaming "it's not fair".  It apparently isn't clear to you that you
have to chip in for the whole thing to be maintainable in the long
term.  Unfair... lol, that was a good one, really.

-- 
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/