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

[Lee Jones]

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

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

> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/