Thread (18 messages) 18 messages, 3 authors, 2014-02-19

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

From: Lee Jones <hidden>
Date: 2014-02-19 16:39:45
Also in: linux-ide, lkml

quoted
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?
That's not what I said was it? You're misinterpreting me.

I'm more than happy to work on core code and have done in the past.
However, if every subsystem maintainer I submit patches to forced me
to undertake some API clean-ups/re-write or convert to another
future/development API prior to acceptance I wouldn't be able to get
any of my own work done.
quoted
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?
It tells me that Hans has more spare time than I do.

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?
Nobody is actually helping Hans' work.  Not at all, nada, zilch.
Just complain when directed towards it.
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.
quoted
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.
It appears you've just regressed into childhood again. Let's continue
this when you are able to have an adult conversation which other
grown-ups.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help